Best practice проектов автоматизации бизнес-процессов. От методологии до инструментария. Часть 1 — интервью с руководителем консалтинговых проектов «Консист Бизнес Групп» Андреем Кочетковым

Любой проект в консалтинговой практике, связанный с разработкой технического задания, функциональных требований или оптимизацией бизнес-процессов — задача трудоемкая, но необходимая для того, чтобы обеспечить базу комплексного проекта, свести в единую картину ожидания заказчика и прогнозируемые результаты. Руководитель консалтинговых проектов «Консист Бизнес Групп» Андрей Кочетков расскажет о том, на что следует обращать внимание, какие трудности могут возникать в проектах и как их преодолевать, поделится особенностями ведения проекта в компании diHouse — крупном оптовом дистрибуторе.

— Андрей, расскажите, пожалуйста, в целом о Ваших проектном опыте, Все ли Ваши проекты включают этап описания бизнес-процессов?

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

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

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

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

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

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

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

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

— Часто ли так случается, что существующие бизнес-процессы меняются при внедрении информационных систем?

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

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

 — Что самое главное, что нужно учесть в работе по оптимизации бизнес-процессов?

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

 — Этой модели достаточно для начала проекта автоматизации?

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

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

— Если сравнивать проекты разных заказчиков, отличаются ли клиенты друг от друга в зависимости от того, например, это государственная компания или коммерческая структура?

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

— Какие ошибки наиболее часто допускаются, на Ваш взгляд, на каждом из этапов? И что Вы предлагаете, чтобы их избежать?

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

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

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

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

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

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

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

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

Продолжение темы — во второй части статьи. Здесь Вы найдете:

• Кейс проекта внедрения ИС в компании diHouse;
• Работа с заказчиком: «одинаково смотрим на вещи»;
• Опыт применения эффективного инструментария для подготовки ТЗ на автоматизацию.

Продолжение выйдет в ближайшее время в разделе публикации, а также в нашей группе «Business Studio для профессионалов» на Facebook.com.

Опубликовано по материалам:
https://megamozg.ru/company/businessstudio/blog/25244/

Апрель 2016 г.

Рекомендуемые материалы по тематике

Как «подогнать по размеру» информационную систему организации

Эффект синергии методологий в проектах трансформации ИТ

Автоматизация — с чего начать?

Построение и развитие ИТ-архитектуры организации