Цель процесса обеспечить устранение инцидентов в предельно сжатые сроки. Инцидент — это любое событие: сбои, запросы на консультации и т.п, которое может привести к понижению качества предоставления услуги. Для успешного управления инцидентами необходимо создание диспетчерской службы (Service Desk)
— Управление проблемами (Problem managment)
Организация процесса направлена на уменьшение количества инцидентов, за счет выявления и устранения причин возникновения инцидентов
— Управление конфигурациями (Configuration managment)
Процесс предназначен для создании и поддержании в актуальном состоянии логической модели инфраструктуры компании
— Управление изменениями (Change managment)
Цель процесса является организация проведения изменений с наименьшим риском возникнованеия инциденитов, вызванных изменениями
— Управление релизами (Release managment)
Цель процесса — обеспечение работоспособности производственной среды при внедрении изменений
Зачем в IT-проекте карта бизнес-процессов?
— Управление уровнем сервиса (Service level managment)
Цель процесса — выявить состав и уровень сервиса на основании требовании потребителей и поставщиков ИТ-сервисов, контролировать достижение установленного уровня сервиса.
— Управление финансами (Financial managment fot IT services)
Цель процесса заключается в обеспечении стабильного финансирования всех прочих процессов
— Управление мощностью (Capacity managment)
Цель процесса исключить возникновение инцидентов, по причине недостаточной мощности ИТ-инфраструктуры компании, и в то же время избежать неоправданных затрат на приобретение излишних, неиспользуемых мощностей.
— Управление непрерывностью (IT service continuity managment)
Организация процесса направлена на обеспечение гарантированного восстановления предоставления ИТ-сервисов до уровня, необходимого для продолжения бизнес-операций за определенный промежуток времени.
— Управление доступностью (Availability managment )
Процесс включает в себя обеспечение согласованного уровня доступности сервиса, а также оценку текущей доступности сервиса и планирование действий, направленных на ее дальнейшее улучшение
Источник: blinovdaniil.wordpress.com
Все процессы компании как на ладони
В данной статье поделюсь, как мы пришли к разработке собственной IT-платформы и на какие грабли мы наступали.
7736 просмотров
Как часто вы сталкивались с попытками регламентировать деятельность в компании? С написанием инструкцией? Насколько быстро они терялись в куче папок на компьютере и превращались в абсолютно бесполезный инструмент? Как быстро Ваши сотрудники открывали и закрывали регламент, состоящий из 20 и более страниц, не дочитав до конца?
Все наши попытки ввести стандарты для процессов заканчивалась неудачей. Большинство бизнес-процессов у нас состоят из более чем 30 шагов и 7-10 участников. Нелегко координировать, помнить кто за кем идёт и что должен сделать, и уж тем более успеть это сделать в срок. Требуется ввести порядок, и при этом создать комфортную среду для сотрудников.
С чего начать Бизнес-аналитику в IT?
Сделаю небольшое отступление.
Отвечу, вкратце, что такое бизнес-процесс?
Это совокупность последовательных действий, направленных на производство и сбыт продукта (услуги), и поддержание стабильного функционирования бизнеса. Простыми словами, это все взаимодействия сотрудников друг с другом, которые проходят по заранее описанному алгоритму.
Примеры бизнес-процессов, которые часто требуют регламентации в компаниях:
- Процесс приема сотрудника на работу.
- Согласование договоров и других документов.
- Процесс закупки.
- Процесс снабжения компании товарами и услугами.
- Процесс обработки потенциальных клиентов.
- И многие другие процессы.
Ниже сформулирую то, с чем мы столкнулись, не имея описанных алгоритмов работы по процессам.
С какими проблемами мы столкнулись?
- Сложные многоуровневые процессы протекали путем общения через почту (или чат) и большая часть накопленной информации терялась в огромных переписках.
- Не было понимания, кто за что нес ответственность, и получали простаивающие процессы и сорванные сроки. А хвостов было не найти.
- Даже самые простые задачи у двух отделов занимали недели.
- Не было прозрачного понимания, где слабое место в процессе и мы не могли на него повлиять, чтобы ускориться.
- Сталкивались с бесконечным правками и переделками.
- И конечно, в итоге страдало качество продукта и усложнялась работа сотрудников (так как не было достаточной информации для решения своего вопроса).
Кстати, напишите в комментариях, если сталкивались с похожими проблемами и как вы их решали. Интересно, одни ли мы такие. =))
Как мы пытались их решать?
Во-первых, мы описали процесс в Visio в виде блок-схем. Постарались визуализировать процесс и уместить на несколько А4.
В качестве примера, прикрепляю описание одного из процессов:
«Обработка заявок/звонков с сайта»:
Описание бизнес-процесса «Обработка заявки/звонка с сайта» Киселев П.Д.
Во-вторых, перенесли блок-схему в дизайнер бизнес-процессов Битрикса. Это наш основной корпоративный портал, поэтому выбор пал на данное ПО.
Дизайнер бизнес-процессов в Битрикс Киселев П.Д.
Ниже пример задания для сотрудника, когда до него доходит «очередь»:
(Есть описание задания, от кого пришло и какое действие нужно совершить. В данном примере просят утвердить выдачу наличных денег, при нажатии на кнопку «Наличные выданы» процесс перейдет на следующий шаг)
Задания бизнес-процессов для сотрудников в Битрикс Киселев П.Д.
Поработав в Битриксе с бизнес-процессами около года, нашли множество багов и неудобств:
- отсутствуют умные фильтры для процесса;
- нет понятного и удобного реестра запущенных процессов;
- не хватает расширенной карточки задания для сотрудника (где есть подробное описание, что и в какой момент следует сделать в рамках процесса, где взять материал и информацию для выполнения, просмотреть комментарии от других участников процесса и главное в какие сроки сделать задание);
- отсутствуют отчеты по бизнес-процессам, чтобы, как минимум, отследить простои и узкие места;
Всё выше перечисленное подтолкнуло начать реализовывать собственную платформу, тем более накопился опыт в бизнес-процессах и их автоматизации. Конечно не с нуля, а на базе существующий IT-решений с открытым кодом.
Решение: IT платформа для трекинга и автоматизации бизнес-процессов компании
Платформу планируем запускать на всех платформах (приложение + веб).
По модели монетизации: Freemium или подписочная модель (часть функционала будет бесплатной + платные расширения) для B2B.
Хотим, чтобы платформа давала возможность удаленного управления сотрудниками: отображала их реальную загрузку, вовремя отправляла уведомления о любых сбоях в работе в рамках бизнес-процессов, кратно сокращала правки и доработки, повышала качество конечного продукта бизнес-процессов.
Платформа разрабатывается для удобной работы не только с компьютера, но и на любом смартфоне.
Акцент делаем на визуализацию! Вы видите на одном DashBoard`е все процессы в тех разрезах, которые действительно помогают принимать правильные управленческие решения.
Как это выглядит?
1. Страница со списком бизнес-процессов.
Наглядно видно, какой процесс на ком остановился и что необходимо сделать, чтобы его продвинуть дальше. Виден прогресс, который отображает, сколько осталось до конца процесса, чтобы получить итоговый результат.
У любого сотрудника есть возможность перейти во вкладку «Мои процессы» и увидеть только свои задания.
Бизнес-процессы компании Киселев П.Д,
2. Подробная карточка задания сотрудника в рамках бизнес-процесса.
Сотрудник, открывая карточку по своему заданию, видит, что именно ему нужно сделать, все прикрепленные документы и материалы (справа сверху), в какие сроки и какие комментарии по данному процессу оставили другие участники. Здесь же в карточке сотрудник прикрепляет документ и выполняет задание, ему не нужно переходить из одного в окна в другое — все в одном месте!
Карточка элемента бизнес-процесса Киселев П.Д.
3. Список всех созданных бизнес-процессов компании.
Создавайте и настраивайте сколь угодно бизнес-процессов в удобном конструкторе (по аналогии с тем, как создаются сайты из блоков в Tilda)
Список бизнес-процессов компании Киселев П.Д.
4. Пример отчетности для руководителей отделов.
Видна загрузка каждого сотрудника, его выполненные и просроченные задания. Также отображается сколько элементов запущено по каждому из бизнес-процессов и динамика по созданным и выполненным элементам.
Отчетность для руководителей отделов (подразделений) Киселев П.Д.
Ожидаемый результат от внедрения платформы
1. Вы ясно понимаете, кто чем занят и на каком шаге процесса.
2. Все сотрудники говорят на одном языке. Каждый знает, что сделать и какой материал подготовить для следующего участника процесса для выполнения его задания.
3. С уходом сотрудника Вы не теряете знание о том, в какой последовательности и как должен идти процесс, чтобы получить результат
4. Вы экономите деньги на передаче знаний новым сотрудникам, благодаря прозрачной и понятной системе процессов.
5. Сотрудник знает, что именно он делает; от кого что получает; в каком виде получает; в какие сроки выполняет работу; кому, когда и что передает; за что отвечает.
6. Наилучшим образом подготовитесь к автоматизации системы управления организацией; благодаря системе, которая выявит неоптимальные пути движения документов и материальных ценностей.
7. Визуализированная картина по используемым ресурсам, а также сколько в среднем занимает выполнение каждого задания.
8. Ваши процессы компании становятся измеримыми и Вы сможете на них влиять онлайн: ускорять, оптимизировать и выводить на новый уровень автоматизации
9. Снижаете человеческий фактор и как следствие количество ошибок, которые приводят к денежным потерям компании
Буду благодарен Вам за обратную связь в комментариях, ваши пожелания и критику еще=)
Источник: vc.ru
СТАНДАРТ УПРАВЛЕНИЯ И КОНТРОЛЯ ИНФОРМАЦИОННЫХ СИСТЕМ (CobiT)
Существует много способов классификации бизнес-процессов. Многие везущие компании, используя процессную ориентацию, провели анализ своей работы и определили список своих основных бизнес-процессов. Например, такая работа проведена компаниями Xerox и IBM. Оказалось, что их списки содержат разное число основных бизнес-процессов. Следовательно, эти списки отражают конкретные задачи, решаемые отдельными компаниями.
В то же время другие заинтересованные организации выполнили ту же работу, но с более общих позиций. Цель – составление достаточно общего списка основных бизнес-процессов, который бы отражал интересы большого числа других компаний. Двумя основными исполнителями в этой группе были Международный центр сбора и анализа бенчмаркннговой информации (IBC – International Benchmarking Clearinghouse) в Хьюстоне и Европейский фонд управления качеством (EFQM).
Моделирование работы предприятий и, как часть этой задачи, определение списков бизнес-процессов выделилось в отдельную самостоятельную область исследований, которой занимаются многие учёные. Например, исследователи из Плимутского университета (США) разработали иерархию бизнес-процессов, которая имеет пять уровней. В этой иерархии процессы делятся на три основные группы: «производство», «отправление» и «поддержка».
Более простой и более прикладной подход был предложен в результате выполнения норвежского проекта ТОРР по сравнительному бенчмаркингу. Эта программа по разработке методов повышения продуктивности производства выполнялась под управлением организации NTNU/SINTEF, находящейся в Трондхейме. В результате для создания предпосылок к разработке методов самооценки и сравнительного бенчмаркинга была предложена структурная схема бизнес-процессов. Все процессы были поделены на первичные (основные) и поддерживающие (вспомогательные) в соответствии с теорией Портера о цепочках добавления стоимости.
К основным операциям относятся операции по созданию добавленной стоимости, имеющие непосредственное отношение к производимому продукту и, тем самым, влияющие на финансовый результат предприятия.
К основным процессам организации, как правило, относят процессы производства, сбыта и снабжения. Строго говоря, к основным процессам следует относить все процессы, добавляющие ценность. Примерами таких процессов являются процессы маркетинга, закупок, производства, хранения, поставки и сервисного обслуживания продукции.
Вспомогательные операции не имеют непосредственного отношения к производимым товарам и услугам, однако, без них невозможно выполнение операций по созданию добавленной стоимости. Вспомогательные процессы напрямую не добавляют ценности, но увеличивают стоимость изделия (услуги, информации). К таким процессам относятся: управление персоналом, управление документацией, техническое обслуживание оборудования, бюджетное управление, административно-хозяйственная деятельность и т. д.
Исходя из такой дифференциации операций, основным процессом является процесс, операции которого имеют прямое отношение к продукту предприятия и тем самым влияют на создание добавленной стоимости. Вспомогательный процесс, напротив, является процессом, операции которого не являются, с точки зрения клиента, важными для создания стоимости, однако, они неотъемлемы при выполнении основного процесса.
Вспомогательные процессы не имеют непосредственных точек соприкосновения с производимыми продуктами или предоставляемыми услугами. Несмотря на названные критерии, чёткое разделение между основными и вспомогательными процессами осложняется тем, что в различных контекстах и для различных предприятий один и тот же процесс может являться как основным, так и вспомогательным. Кроме того, вспомогательные процессы могут переходить в основные процессы и наоборот. Например, в отличие от традиционных процессов торгового предприятия, при т. н. центральном регулировании продаж, торговое предприятие не занимается логистическими операциями в основном процессе, а концентрируется на операциях по управлению. Таким образом, логистика, традиционно являющаяся в торговле основным процессом, становится вспомогательным процессом.
Некоторые из поддерживающих (вспомогательных) процессов были потом выделены в отдельный класс – процессов развития. Эти три группы процессов определяются следующим образом:
• Первичными процессами называются основные и создающие ценности процессы предприятия. Эти процессы пронизывают всю компанию, начиная с потребителя и заканчивая поставщиками.
• Поддерживающие (вспомогательные) процессы не создают непосредственно добавленную ценность. Они нужны для обеспечения основных процессов. Такими вспомогательными процессами могут быть, например, управление финансами и персоналом.
• Развивающиеся процессы – это такие процессы, которые позволят создать цепочку ценности в основном и во вспомогательном процессах на новом уровне показателей. Примеры: разработка продукции и развитие каналов товародвижения.
Результаты, полученные при выполнении проекта ТОРР по сравнительному бенчмаркингу, получили дальнейшее развитие при выполнении программы ENAPS (Европейская сеть изучения перспективных показателей). Эта программа финансируется Европейской Комиссией. Программа предназначена для создания базы данных для европейской системы сравнительного бенчмаркннга.
В результате выполнения работ по программе ENAPS были приняты другие названия групп бизнес-процессов, а не те, что в ТОРР программе. Первичные бизнес-процессы были названы собственно бизнес-процессами. Они были разбиты на четыре подгруппы основных процессов. Две другие группы процессов были названы вторичными процессами, которые в свою очередь делятся на группы процессов поддержка и процессов развития. На рисунке 4 показана общая структурная схема процессов, разработанная в рамках программы ENAPS, а также её составляющие.
Рис. 4 – Классификация бизнес-процессов
При классификации процессов по отношению к функциональным звеньям выделяют три основные группы процессов:
– сквозные процессы, проходящие через несколько подразделений организации или через всю организацию, пересекающие границы функциональных подразделений. Сквозные процессы часто называют межфункциональными процессами;
– процессы (подпроцессы) подразделений, деятельность которых ограничена рамками одного функционального подразделения организации. Такие процессы называют внутрифунциональными процессами;
– операции (функции) самого нижнего уровня декомпозиции деятельности организации, как правило, операции выполняются одним человеком.
Процессы могут быть классифицированы и по другим признакам, например:
1. По отношению к клиентам процессов:
2. По уровню подробности рассмотрения:
2.1. Верхнего уровня;
2.3. Элементарные (операции, не требующие более детального описания).
Одним из важнейших вопросов, возникающих при моделировании бизнес-процессов, является определение необходимой глубины описания. При проведении декомпозиции моделей количество объектов на диаграмме растёт в геометрической прогрессии. Поэтому всегда очень важно изначально определить практическую целесообразную степень детальности описания.
Верхний уровень описания бизнес-процессов соответствует процессам, управляемым заместителями генерального директора. Второй уровень процессов, как правило, рассматривается на уровне процессов крупных подразделений организации. Третий уровень – уровень процессов (функций) подразделений и отделов. Четвёртый уровень – функции (операции), выполняемые на рабочих местах и т.д. Следует обратить внимание, что количество объектов модели при декомпозиции может стать очень большим.
Стандарт разработан Фондом аудита и контроля информационных систем (ISACA) с целью создания рекомендаций для построения и контроля информационной среды.
В случае использования методологий CobiT информационная система строится исходя из требований бизнеса и условий жесткой экономии ресурсов, а также эффективного использования этих ресурсов. Другими словами, CobiT описывает бизнес-ориентированный подход к созданию информационной среды: ИТ рассматриваются в виде инструмента бизнеса, а стандарт определяет принципы построения и организации работы ИТ-департамента.
CobiT (сокращение от Control Objectives for Information and Related Technology («Задачи информационных и смежных технологий») — представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления ИТ, аудита и ИТ-безопасности. Создатели стандарта провели анализ и оценку и объединили лучшее из международных технических стандартов, стандартов управления качеством, аудиторской деятельности, а также из практических требований и опыта — все то, что так или иначе имело отношение к целям управления.
Задача CobiT заключается в ликвидации разрыва между руководством компании с их видением бизнес-целей и ИТ-департаментом, осуществляющим поддержку информационной инфраструктуры, которая должна способствовать достижению этих целей.
Нередко руководство компании в силу объективных причин не понимает ИТ-специалистов. По представлению руководства, сотрудники ИТ-подразделения разговаривают на каком-то птичьем языке. Те, в свою очередь, не понимают бизнес-терминов, на основании которых строятся распоряжения руководства. Это все приводит к росту издержек, выполнению лишней работы, что, конечно же, сказывается на эффективности деятельности компании.
CobiT, благодаря единой терминологии, служит своеобразной платформой-буфером для конструктивного диалога между всеми участниками бизнеса:
– руководителями среднего звена (ИТ-директором, начальниками отделов);
– непосредственными исполнителями (инженерами, программистами и т. д.);
В CobiT детально описаны цели и принципы управления, объекты управления, четко определены все ИТ-процессы (задачи), протекающие в компании, и требования к ним, описан возможный инструментарий (практики) для их реализации. В описании ИТ-процессов также приведены практические рекомендации по управлению ИТ-безопасностью.
Кроме того, CobiT вводит целый ряд показателей (метрик) для оценки эффективности реализации системы управления ИТ, которые часто используются аудиторами ИТ-систем. В их число входят показатели качества и стоимости обработки информации, характеристики ее доставки получателю, показатели, относящиеся к субъективным аспектам обработки информации (например стиль, удобство интерфейсов). Оцениваются показатели, описывающие соответствие компьютерной ИТ-системы принятым стандартам и требованиям, достоверность обрабатываемой в системе информации, ее действенность, общепринятые показатели информационной безопасности — конфиденциальность, целостность и доступность обрабатываемой в системе информации.
Основная идея CobiT состоит в том, что организация работы ИТ-департамента должна быть основана на отдельных процессах, а не на функциях. В отечественной практике в большинстве случаев существует функциональное разделение обязанностей и ответственности, что может привести к появлению бесконтрольных областей (например, при назначении группы администраторов локальной сети, ответственных за эксплуатацию нового сегмента сети, возникновение нештатной ситуации на границе сетей иногда провоцирует конфликт, связанный с распределением ответственности за граничный участок). Описание деятельности ИТ-департамента посредством процессов позволяет определить оптимальное соотношение между возможностями ИС и требованиями, возникающими в ходе деятельности организации. Следует подчеркнуть, что любой процесс имеет определенную достижимую цель. Поэтому работа ИТ-департамента в целом должна рассматриваться как процесс, направленный на поддержание основной деятельности организации и на обеспечение пользователей необходимой информацией.
У каждого процесса есть входные (ресурсы) и выходные (конечный продукт) данные, а также параметры работы (требования, ограничения и т. п.). Общая модель использования ресурсов, ограничений и требований, разделенная на процессы, позволяет оптимизировать работу ИТ-департамента. Кроме того, такое разделение на процессы помогает четко распределить ответственность. Для простоты восприятия стандарт CobiT описывает все внутренние процессы ИТ-департамента в виде иерархической структуры.
На первом уровне выделены четыре базовых процесса (домена), заключающих в себе основные виды деятельности ИТ-департамента:
‑ планирование и организация;
‑ приобретение и внедрение;
‑ поставка и поддержка;
Второй уровень иерархической структуры содержит более 30 процессов, каждый из которых детализирован и рассмотрен подробно на третьем уровне. Для всех процессов описаны методы управления и контроля, что позволяет использовать стандарт CobiT на всех жизненных стадиях информационной системы, начиная с построения ее эффективной модели и заканчивая управлением, контролем и аудитом.
В CobiT следует выделить три основополагающих этапа построения эффективной модели ИТ-департамента, которые надо выполнять последовательно.
Первый этап заключается в сопоставлении возможностей информационной системы (ее ресурсов) с требованиями, возникающими в ходе деятельности организации (так называемые требования бизнес-процессов). Возможности системы рассматриваются как совокупный эффект от использования имеющихся ресурсов: квалифицированного персонала, программных и аппаратных средств, технологий. Для определения требований бизнес-процессов необходимо дать качественную оценку требований к информации на основе следующих критериев:
Исходя из требований к информации последовательно реализуется второй этап, который определяет использование целевых ресурсов, входные и выходные данные для каждого процесса, направленного на достижение целей бизнеса. Все целевые ресурсы подразделяются на пять категорий: кадры, приложения, технологии, средства информатизации, данные.
И наконец, после определения процессов на втором этапе сравнивается их совокупный конечный продукт с требованиями бизнес-процессов. Таким образом, круг замыкается. Соответствие между целями организации и деятельностью ИТ-департамента сохраняется постоянно.
Таким образом, стандарт CobiT позволяет оценивать текущую деятельность ИТ-департамента с трех сторон: с точки зрения процессов, ресурсов и бизнес-требований к информации.
С практической точки зрения стандарт CobiT является руководством по управлению инвестициями, оценке рисков и аудиту информационных систем. Для российского бизнеса этот стандарт особенно актуален, так как по мере роста ИТ-департаментов довольно остро встает кадровая проблема. Кроме того, резкая смена отношения российских организаций к информационным технологиям заставляет руководителей ИТ-департаментов ориентироваться в быстро меняющейся среде, предугадывая перспективы того или иного продукта. Но время идет, бурный и хаотичный рост сменяется целенаправленным движением в сторону экономии и повышения качества предоставляемых услуг. Очевидно, что на российском рынке акценты уже смещаются от тотальной автоматизации различных бизнес-функций в сторону поддержки бизнес-процессов.
Отличие CobiT от других стандартов заключается в подходе к организации работы ИТ-департамента. В случае использования методологий CobiT информационная система строится исходя из требований бизнеса и условий жесткой экономии ресурсов, а также эффективного использования этих ресурсов. Другими словами, CobiT описывает бизнес-ориентированный подход к созданию информационной среды. ИТ рассматривается в виде инструмента бизнеса, а стандарт определяет принципы построения и организации работы ИТ-департамента.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
