ноябрь    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 / Выпуск №05 (68) / Проектирование ИТ-процессов

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

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

Проектирование ИТ-процессов

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

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

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

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

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

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

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

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

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

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

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

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

Как и многие другие термины, «проектирование» понимают по-разному. Простое обыденное понимание рассматривает проектирование процессов как их строгую регламентацию. Однако никто не настаивает именно на таком определении.

В проектировании процессов принято выделять четыре уровня:

• Регламентация – четкое определение выполняемых действий.
• Нормирование – определение характеристик выполняемых действий.
• Инструктирование – передача опыта по выполнению действий.
• Целеполагание – определение целей в рамках выполнения процесса.

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

Конечно, можно ограничиться чем-то одним, а можно рассмотреть и все четыре уровня. Все зависит от процесса. Причем обычно при проектировании процесса двигаются снизу вверх:

• сначала формируют цели;
• потом передают опыт;
• потом определяют нормы;
• и, если необходимо, определяют регламенты.

В таблице 1 приведены четыре уровня проектирования и эффективность их использования в зависимости от типа процесса.

Таблица 1. Уровень проектирования процесса в зависимости от его характеристик

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

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

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

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

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

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

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

Другим критерием хорошо спроектированного процесса может служить его эффективность, которая в общем случае состоит из различных аспектов. Например, с помощью BSC (Balanced ScoreCard – сбалансированной системы показателей) Нортона и Каплана можно выделить следующие области эффективности процессов: финансы, потребители, структура, технологии, исполнители. В простейшем случае эффективность процесса можно рассматривать только в финансовом аспекте, сравнивая затраты на процесс с полученными от его использования за определенный период времени финансовыми результатами.

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

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

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

На рис. 1 приведена схема процесса управления проблемами для поддержки системы на платформе 1С из реального проекта.

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

Вы не увидите на этой схеме элементарных функций, это укрупненное проектирование процесса.

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

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

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

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

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

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

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

В теории реинжиниринга оба метода прекрасно уживаются. Мало того, на современном этапе наука отдает предпочтение первому.

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

Конечно, то, что есть, все равно придется описывать, чтобы определить гап (Gap) или расхождение между тем, что есть, и тем, чего хочется достичь. А потом решить, как этот гап будет преодолеваться. Но это уже несколько иная история.

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

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

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

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

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

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

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

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

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

При этом отбор идей также может проходить в форме брейнсторминга, но уже другого.

Оптимальный размер группы участников брейнсторминга от семи до двенадцати человек.

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

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

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

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

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

Различают следующие стадии брейнсторминга:

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

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

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

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

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

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

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

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

Некоторые задачи на сообразительность для начала брейнсторминга:

1. Какой ответ зашифрован в числовом ряду: 10--9--8--7--6-- --4--3--2--1--0 . А вопрос такой: «Почему пес Барбос сегодня не хочет есть мясо?»
2. 16 музыкантов одного духового оркестра играют перед зрителями, но их никто не слушает. Почему?
3. Что не может войти даже в самую большую кастрюлю?
4. Как вы думаете, что такое большое, как Эйфелева башня, но при этом не весит ни грамма?

В начало⇑

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

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