ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

28.09.2024

Чем страшен ИИ, и с чем его едят

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2017 / Выпуск №04 (67) / Жизненный цикл ИТ-процесса

Рубрика: ИТ-процессы

Марина Аншина, президент фонда ФОСТАС, председатель Комитета по стандартам Российского Союза ИТ‑директоров

Жизненный цикл ИТ-процесса

Термин «жизненный цикл» в применении к процессу имеет двоякий смысл. По отношению к шаблону процесса – той структуре, в которую он заключен, как поток в берега, – это одно, а в каждом выполняемом экземпляре процесса – именно том, что «течёт» в этих берегах, – совершенно другое. Ведь процесс представляет собой повторяемую деятельность, выполняется не его абстрактная эталонная схема или шаблон процесса, как его иногда называют вавтоматизированных системах, а конкретный экземпляр. И именно этот экземпляр должен давать те результаты, на которые мы рассчитывали, проектируя шаблон процесса. В дальнейшем, говоря о жизненном цикле процесса, мы будем иметь в виду шаблон процесса, переходя к экземпляру, – указывать на это явно

Давайте сначала определим жизненный цикл «канала» процессного потока, т.е. шаблона процесса.

Жизненный цикл шаблона процесса

Любой процесс состоит из операций, которые следуют одна за другой синхронно или выполняются параллельно, асинхронно. Операция, в свою очередь, может состоять из других операций, тогда ее называют составной. Операция, которая не содержит других операций, называется элементарной. Кроме операций, в процесс обычно включаются события и условия. События отражают ключевые моменты выполнения процесса, в частности, те, которые надо подчеркнуть или проконтролировать, а условия определяют его развитие – следование операций. Условия можно сравнить с заслонками и задвижками, которые направляют поток операций в нужную сторону.

Таким образом, формируется шаблон процесса, представляющий собой его формализованную структуру, пригодную для дальнейшего использования в деятельности организации, а именно выполнения его экземпляров. Причем одновременно может выполняться произвольное количество таких экземпляров.

Описание процесса мы уже кратко обсуждали в предыдущих статьях. Однако стоит повторить, что для описания шаблона процесса в соответствии с выбранной архитектурной моделью процесса надо определить следующее:

• уровень данных – данные, которые сопровождают выполнение процесса
• уровень ресурсов – ресурсы разного типа, потребляемые при его выполнении
• уровень операций – шаги выполнения процесса
• уровень управления – управляющие воздействия, предусмотренные для потока операций

С некоторых пор, а точнее, с середины прошлого века, создание шаблона процесса принято рассматривать как специальную область инженерной деятельности, в которой разрабатываются не новые устройства, а операции и процессы.

Хотя процесс можно описать текстом или в таблицах, удобнее делать это в графической форме. Что, впрочем, совсем не исключает двух вышеприведенных вариантов, а лишь прекрасно дополняет их, представляя процесс с большей наглядностью. Для этого существует значительное количество средств: языков и нотаций. Причем первые отличаются от вторых строгостью правил. Если язык существует в относительной вольнице, то нотация требует неукоснительного следования своим законам.

Все те, кто в той или иной форме изучал программирование, естественным образом используют для графического представления процессов блок-схемы. Действительно, в них есть специальные значки и для операций, и для событий, и дляусловий. На рис. 1 приведена блок-схема процесса управления проблемами.

Рисунок 1. Блок-схема процесса управления проблемами

Блок-схемы можно рисовать практически в любом редакторе. Но за такую свободу приходится платить тем, что проверить правильность такой схемы можно только визуально.

Старейшие специализированные методы графического отображения процессов делятся на два типа: диаграммы потоков данных DFD (Data Flow Diagram) и диаграммы потоков работ WFD (Work Flow Diagram). Диаграмма потоков данных описывает входы-выходы, управляющие воздействия процесса, а также необходимую для этого информацию. Диаграммы потоков работ описывают процесс в терминах операций, их логики выполнения и в масштабах времени.

Коль мы заговорили о графическом представлении процесса, нельзя не сказать об IDEF, ARIS и BPMN как об основных на настоящий момент нотациях такого представления. В отличие от блок-схем они обладают правилами, а графические редакторы позволяют автоматически проверить соблюдение этих правил.

IDEF, или Integration Definition for Function Modeling, развивается с начала 80-х годов прошлого века и представляет собой семейство нотаций моделирования, из которых наиболее известны IDEF0, описывающий функционал и управление операциями, и IDEF3, включающий логику выполнения операций. Кроме того, в семействе IDEF есть ряд нотаций для описания данных и оргструктуры выполнения процесса. В отличие от блок-схем, которые можно нарисовать практически в любом графическом редакторе, для IDEF существует ряд программных продуктов, из которых наиболее популярен BPwin. На рис. 2 приведена простейшая схема процесса согласования договора в IDEF3.

Рисунок 2. Пример согласования договора в IDEF3

ARIS (Software AG), или Architecture of integrated Information Systems, был предложен Ф.-В. Шеером в 1992 году. ARIS как более молодой по отношению к BPwin продукт, созданный на основе обширного опыта описания процессов, исложнее, и строже. Его несомненным преимуществом, сильно способствующим росту популярности, является то, что он встроен во многие ERP-системы, например OEBS и SAP. Ограниченную по функционалу версию ARIS – ARIS Express можно скачать бесплатно.

BPMN – Business Process Management Notation – представляет собой самое молодое и активно развивающееся направление моделирования процессов. В отличие от вышеупомянутых нотаций оно является стандартом описания процессов, разработанным международным консорциумом OMG (Object Management Group), а различные поставщики предлагают его реализации. В отличие от вышеупомянутых нотаций BPMN хорошо подходит для описания совместной работы исполнителей по выполнению процесса.

Кроме того, идея использования способов формализации требований к программному обеспечению и подготовки ТЗ для описания процессов остается по-прежнему привлекательной. Да и неудивительно: все больше процессов частично, аиногда и полностью автоматизированы.

Например, UML (Unified Modelling Language) – еще один стандарт OMG, разработанный для объектно-ориентированного программирования и предлагающий для этого набор диаграмм по примеру проекций для представления вида архитектурного сооружения, зачастую используется и для описания процессов. Мне даже известен случай, когда именно UML послужил корпоративным средством такого описания, используемого не только разработчиками, но и бизнес-клиентами.

Кроме того, любую графическую модель процесса можно представить в виде swim lane диаграммы (диаграмма плавательных дорожек), которая схему процесса располагает по «дорожкам» бассейна, причем по каждой такой дорожке «плывет» только определенная команда исполнителей процесса.

Такое графическое представление позволяет функциональному подразделению сразу увидеть те операции и связывающую их логику, которые оно должно выполнять и за которые отвечает. Эти диаграммы очень популярны и хорошо воспринимаются командами, выполняющими процесс.

Выбор метода представления процесса является, конечно, важной составляющей процессного управления, но в конце концов это всего лишь инструмент, который просто должен попасть в умелые руки. Поэтому средства описания процессов не являются темой этой статьи. Да и написаны об этом тонны литературы.

Давайте вернемся к жизненному циклу процесса. Прежде чем приступить к разработке процесса или кардинальным изменениям, необходимо определить его цели и область применения, а затем требования к нему и ограничения на еговыполнение. После этого стоит выяснить, как мы узнаем, что достигли целей и выполнили ограничения, т.е. сформировать показатели достижения цели. Кроме того, нелишне задуматься о компасе, который на протяжении жизненного цикла будет указывать нам, двигаемся ли мы в нужном направлении.

Такие показатели называют обычно показателями производительности или эффективности. То есть копая канаву, стоит регулярно проверять, правильно ли мы ее копаем. А то получится, что узнаем мы об этом только в самый последний момент, когда что-то поправить будет уже поздно. Все это определяет предварительную стадию жизненного цикла процесса. Если проектирование процесса выполняется в рамках проекта, эта стадия совпадает с предпроектной стадией.

После этого начинается стадия собственно проектирования процесса, которая может состоять из таких шагов, как разработка различных макетов процесса с постепенным уточнением его составляющих, согласование таких макетов сзаинтересованными лицами и, наконец, получение согласованного и полного шаблона процесса.

Затем начинается стадия внедрения процесса, которая также может заключаться в ряде шагов, таких как тестовая, опытная, опытно-промышленная эксплуатация.

После внедрения процесс, реализуемый своими экземплярами, некоторое время более-менее спокойно выполняется. Параметры достижения его целей и показатели его производительности постоянно отслеживаются и контролируются. Привыявлении нарушений запускается процесс управления изменениями, который происходит в рамках процесса управления изменениями.

Такой процесс обычно один для всех процессов организации. Без управления изменениями шаблон процесса довольно быстро может стать бесполезным, а экземпляры перестанут ему соответствовать и использовать его как эталон. Пример жизненного цикла шаблона процесса приведен на рис. 3.

Рисунок 3. Жизненный цикл шаблона процесса

Однако, сохраняя реалистичность, надо признать, что в какой-то момент для реализации изменений придется выйти за рамки наложенных на процесс ограничений. Тут позволю привести выведенную мной из наблюдений аксиому, гласящую, что разработанный процесс подходит только и именно для тех условий, для которых разработан.

Считать, что мистическим образом его можно использовать более широко, чем предполагалось, – одно из самых грубых заблуждений процессного подхода. Поэтому при проектировании процессов надо пытаться соблюдать баланс между ихрегламентированностью и гибкостью. Гибкий процесс труднее контролировать и автоматизировать. Соответственно, он больше зависит от исполнителей. Жестким стандартизованным процессом легче управлять и его проще автоматизировать, но его срок жизни значительно короче.

Ошибочная практика многих процессов состоит в том, что их используют в ситуациях, весьма далеких от тех, для которых они предназначались. При этом они зачастую становятся тормозом деятельности компании и препятствуют еенормальному развитию. То есть поток, который протекал в вырытой нами канаве, становится бесполезным и канаву надо рыть уже в другом месте. При этом мелкие изменения, заключающиеся в добавлении отводов и устройстве запруд, уже не работают.

Очень важно не прозевать этот момент и вовремя признать, что существующий процесс входит в свою последнюю стадию – вывода из эксплуатации. Не стоит думать, что на этой стадии можно обойтись малой кровью и для вывода процесса из эксплуатации не понадобится ни дополнительных ресурсов, ни дополнительных усилий. Вывод из эксплуатации и переход на новый процесс, у которого могут быть и другие цели, и другие ограничения, требует обычно значительных усилий и затрат ресурсов.

Но и это еще не все. После вывода из эксплуатации возникает заключительный этап постанализа и архивирования результатов процесса. Такая информация является неоценимым сокровищем для последующего развития процессов организации.

Жизненный цикл экземпляра процесса

Отношения, связывающие шаблон процесса и экземпляр процесса, можно сравнить с отношениями, существующими в программировании между типом переменной и ее значением. А именно определение процесса содержит схему экземпляра процесса, типы данных, названия ролей, описание событий, набор операций и логических условий их выполнения. В выполняющемся экземпляре процесса операции происходят в определенной последовательности, зависящей от тех условий, которые были определены в шаблоне процесса.

Эти условия могут относиться к времени и месту выполнения экземпляра процесса, определяться другими процессами или проектами или выполнением других экземпляров, зависеть от доступности тех или иных ресурсов. Конкретные значения этих условий и определяют последовательность и состав операций экземпляра. Также в экземплярах процесса на роли назначаются конкретные исполнители, а структуры и типы данных наполняются полноценным содержанием.

Жизненный цикл экземпляра процесса обычно начинается с подготовительного этапа, в рамках которого происходит формирование всех ресурсов, которые нужны для его выполнения. На этом этапе осуществляется необходимая конкретизация тех неопределенных параметров, которые были заложены в шаблоне процесса.

В терминах канала воды, который мы выбрали в качестве метафоры, прежде чем пустить поток в канал, надо все проверить, в частности не угрожает ли качество воды окружающей среде, и открыть первую заслонку.

После подготовительного этапа экземпляр выполняется в соответствии с шаблоном процесса: заслонки открываются в зависимости от конкретных значений параметров, поток операций течет по каналу, рассчитываются показатели производительности.

Например, для экземпляра процесса управления изменениями, инициированного пользователем, можно предложить следующую систему показателей:

• Время первичной обработки запроса на изменение
• Время анализа изменения
• Качество анализа изменения
• Время согласования изменения
• Время выполнения изменения
• Качество выполнения изменения
• Количество инцидентов, связанных с изменением
• Затраты на выполнение изменения
• Удовлетворенность инициатора изменения

Если же изменение инициировано другим процессом, например управлением проблемами, то первый и последний показатели теряют смысл.

Обычно шаблон процесса разрабатывается таким образом, чтобы предусмотреть прерывание экземпляра процесса в случае наступления каких-то особых нештатных ситуаций.

Например, в ситуации прекращения выделения необходимых ресурсов из-за форс-мажорных обстоятельств. В такой ситуации экземпляр процесса может либо остаться в ожидании нормализации ситуации, либо прекратиться окончательно. На рис. 4 приведен пример жизненного цикла экземпляра процесса.

Рисунок 4. Жизненный цикл экземпляра процесса

Результаты выполнения экземпляров процесса полезно выводить на приборную доску процесса, что позволяет визуализировать процесс и существенно упрощает его анализ.

Жизненный цикл экземпляра процесса зависит от того, на каком этапе жизненного цикла шаблона процесса он выполняется. На этапе внедрения шаблона прерывания происходят довольно часто, а анализ процесса занимает существенную часть его выполнения. Это позволяет улучшать шаблон для того, чтобы обеспечить его дальнейшую эффективную эксплуатацию.

Также и на заключительной стадии шаблона процесса, когда он перестает соответствовать внешним условиям и учтенным ограничениям, прерывания возникают часто. Обычно увеличение таких прерываний как раз и свидетельствует о том, что срок жизни шаблона процесса подходит к концу.

Состояние или статус экземпляра процесса определяются обычно следующим:

• Его местом в жизненном цикле шаблона процесса. Выполнение процесса в тестовом режиме может предполагать дополнительные ресурсы, дополнительные события и управление. Такие экземпляры могут быть совершенно особенными и не повторяться на других стадиях жизненного цикла шаблона процесса
• Его взаимодействием с другими экземплярами, в частности конкуренцией за ресурсы
• Волей руководителей, обладающих полномочиями изменять выполнение экземпляра процесса

Состояния экземпляра процесса в рамках его жизненного цикла можно определить следующим образом:

• Подготовка к выполнению
• Ожидание события, в частности, момента времени (иногда это состояние называют ожидание) или выделения ресурсов (что может формировать очередь процессов)
• Прерывание выполнения, которое может сопровождаться:
  • ожиданием возобновления, не возвращая ресурсы
  • сном – ожиданием возобновления с освобождением всех возможных ресурсов
• Выполнение в ручном режиме
• Выполнение в автоматическом режиме, если процесс или часть его операций автоматизирована
• Прерывание

Жизненный цикл экземпляра, начинающийся с подготовительных действий, завершается либо его выполнением, либо прерыванием без последующего возобновления. Для каждого экземпляра формируется система показателей, которые должны быть отслежены и проанализированы. Необходимая информация, определенная при проектировании процесса, относящаяся к экземпляру, должна быть передана в архив.

Анализ показателей экземпляров может стать источником изменений и даже привести к завершению жизненного цикла шаблона процесса.

Особенности жизненного цикла процесса

Процессное управление насчитывает не один десяток лет развития. Однако обсуждение этой темы без упоминания современных тенденций было бы не полным. Тем более что в управлении процессами в наше время происходят огромные сдвиги.

Прежде всего они связаны с тем, что у современного предприятия требования к гибкости намного выше, чем у его исторических предшественников. Бизнес диктует постоянные изменения, выиграть в конкуренции может только такомпания, которая умеет к ним быстро приспособиться. В такой ситуации жесткие регламентированные процессы, которые, с одной стороны, позволяют организовать эффективное управление, с другой – становятся тормозом преобразований.

Поэтому все активнее развиваются технологии гибкого управления процессами, в частности бизнес-процессами и технологическими процессами. Если раньше внедрение или изменение шаблонов бизнес-процессов осуществлялось спомощью проектов, которые носили гордое звание BPR (Business Process Reengineering – реинжиниринг бизнес-процессов), то сейчас наиболее популярной технологией для этого является BPM (Business Process Management – управление бизнес-процессами).

Если прежде такие изменения происходили относительно редко, для чего подходила сложная и дорогая методика проектного управления, то сейчас подобные изменения совершаются в рамках повседневного оперативного управления.

Но и это еще не все. Все большие обороты набирают такие технологии, как ACM (Adaptive Case Management – адаптивное управление по событиям) и Event-driven enterprise (управляемое событиями предприятия), привязывающее выполнение процессов и всю деятельность предприятия к происходящим событиям. Такие технологии обычно являются самообучающимися, что позволяет, определив логику выполнения процесса в случае известных событий, расширять иуточнять их выполнение на основании действий исполнителей и анализа результатов.

Социальный ВРМ для выполнения процесса использует социальные группы, иногда, как в случае краудсорсинга, внешние по отношению к предприятию, что позволяет обеспечить максимальную гибкость назначения исполнителей иповысить качество процессов за счет привлечения большого количества участников.

Другая очевидная тенденция управления процессами, активно влияющая на их жизненный цикл – это массовая их автоматизация. Позволю привести еще одну аксиому, которая, к сожалению, пока не получила того массового распространения, для которого, несомненно, предназначена. Дело в том, что все рутинные, хоть сколько бы то ни было повторяющиеся операции или целые процессы должны быть автоматизированы.

Действительно, современный человек плохо предназначен для выполнения таких скучных действий. Он неизбежно испытывает тоску, впадает в хандру и даже заболевает. Его эффективность падает, а качество результата оставляет желать лучшего. Компьютер же умеет прекрасно справляться с подобной деятельностью. А вот чтобы научить его интеллектуальной работе, приходится затрачивать существенные силы.

С точки зрения процессов разделение труда очевидно: повторяющиеся, устоявшиеся операции выполняет машина, в непредопределенных случаях управление берет на себя человек. Если же такие случаи регулярно повторяются, то этопросто еще один канал для процесса, который после формализации, либо меняя шаблон процесса, либо в рамках реализации изменений, человек может передать на выполнение машине.

Жизненный цикл процессов ИТ

До этого места мы с вами обсуждали жизненный цикл процессов в общем, без учета специфики ИТ. Однако, как вы понимаете, такая специфика, несомненно, существует.

Прежде всего, как ни прискорбно это сообщать, поговорка «Сапожник без сапог» далеко еще не потеряла своей актуальности. Так случилось, что за последние несколько дней мои собеседники неоднократно признавались в том, чтопроцессы ИТ организованы в их компаниях существенно хуже тех процессов, для автоматизации которых предназначены. Парадоксальность такой ситуации заключается в том, что качество автоматизированных процессов напрямую зависит от качества процессов ИТ. Поэтому из этой ситуации вытекает следующий вывод: оценка и анализ процессов организованы из рук вон плохо. Иначе уже давно бы руководители предприятий обратили на процессы ИТ самое пристальное внимание.

Как- то особенно грустно писать об объективных причинах такой ситуации, заключающихся в том, что ИТ на большинстве российских предприятий по-прежнему находится на одном из последних мест по вниманию топ-менеджмента. Ипричину плохих процессов они ищут где угодно, но только не тут.

В частности, как можно развивать Agile в применении к процессам и ожидать хороших результатов, когда такие важнейшие процессы ИТ, как управление проблемами и управление изменениями, оставляют желать лучшего? Да и Agile вуправлении бизнес-процессами, очевидно, должен сопровождаться грамотным Agile в управлении процессами ИТ. Причем с последнего стоило бы начинать.

При этом современные тенденции, о которых мы немного поговорили выше, в области ИТ еще заметнее. Действительно, если процесс автоматизирован, то изменение его ИТ-составляющих должно происходит быстрее, чем его изменение, поскольку является только частью последнего.

Есть и кое-что хорошее. Процессы ИТ, как я уже писала в предыдущих статьях, достаточно хорошо описаны и изучены. Поэтому первые стадии жизненного цикла шаблона процесса ИТ можно сократить за счет использования таких стандартов, как ИСО/МЭК 15288 и 12207 или 20000 и лучших практик, таких как ITIL и COBIT.

Тут, однако, нас подстерегает другая опасность. Многие ИТ-руководители, потратив ресурсы и усилия и разработав наконец шаблон процесса, держатся за него, как утопающий за соломинку, и не согласны его менять ни за какие коврижки. Такие технологии процессного управления, как управление по событиям или ВРМ, им обычно неведомы. А пережитые трудности разработки и внедрения шаблона процесса ИТ заставляют противиться любому его изменению. Поэтому, даже если процесс ИТ формализован и внедрен, он часто настолько устарел, что приносит не пользу, а исключительно вред.

Грамотное управление процессами, несомненно, требует определенного склада характера, который заставляет изо дня в день кропотливо заниматься выполнением операций, анализом процесса и принятием решений по его непрерывному улучшению. Психологически для многих людей это намного сложнее, чем выполнить проект, утереть пот со лба и немного передохнуть. Кроме того, поскольку проектная деятельность заметнее, то и общее признание там значительнее. Ксчастью, у нас с вами впереди еще несколько статей, в которых мы сможем разобраться и с этим вопросом.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи