21.11.2016

Рецепты успешного консультирования: от методологии до инструментария

Андрей Кочетков – Руководитель консалтинговых проектов «Консист Бизнес Групп»

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Т.е. процесс обследования получился более длительный, чем вы ожидали?

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

Находясь в процессе описания бизнес-процессов компании diHouse, как Вы можете оценить их качество выполнения на тот момент?

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

Расскажите поподробнее, как в проекте diHouse сочеталось и проектирование, и описание бизнес-процессов?

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

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

Скажите использовали ли вы при проектировании процессов так называемые Best Practice?

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

Проект diHouse включал все стандартные этапы работ, о которых Вы говорили?

Да, конечно. В результате проекта была представлена концепция автоматизации и так называемый TO DO лист. То есть результат содержал два аспекта: программу автоматизации и программу изменений, которые необходимы, чтобы улучшить бизнес-архитектуру компании. Разработка технического задания в данном проекте не выполнялась.

Как были организованы работы по проекту со стороны заказчика? Насколько руководители и сотрудники были задействованы в проекте?

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

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

Каковы дальнейшие направления развития этого проекта?

После завершения проекта в соответствии с нашей концепцией автоматизации первым необходимым шагом являлся проект по внедрению B2B площадки. В данном случае нами была рекомендована платформа Hybris компании SAP. По результатам нашего анализа, который также был представлен в концепции автоматизации, этот продукт наилучшим образом подходил под разработанные функциональные требования и позволял развивать процессы под стратегические цели бизнеса нашего заказчика. В проекте внедрения были уточнены требования к автоматизации, учтены все сильные стороны компании, были разработаны технические спецификации по разработке и интеграции с существующими информационными системами. Внедрение такой площадки необходимо было выполнить в достаточно короткие сроки. И на сегодняшний день этот проект успешно завершен. Следующим проектом по автоматизации являлось внедрение платформы Oracle Transportation Management, который также успешно завершен.

Для описания бизнес-процессов diHouse вы использовали Business Studio. Скажите, пожалуйста, какие плюсы дало использование программы?

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

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

В результате проекта в компании diHouse были развернуты два web портала Business Studio – модель бизнес процессов «до оптимизации» и модель оптимизированных бизнес-процессов. Таким образом сотрудники могут в любое время проанализировать, насколько их текущие выполняемые функции отличаются от эталонных оптимизированных вариантов, и скорректировать процессы в системе Business Studio самостоятельно.

В проектах внедрения ИС информация по процессам используется техническими специалистами, как первичный источник понимания бизнеса и особенностей Заказчика. На этапе подготовки к внедрению информационных систем первое, что технические специалисты, разработчики и консультанты по информационным системам видят и узнают о бизнесе Заказчика –  это архитектура бизнеса компании, модель бизнес-процессов в Business Studio. Как показывает практика, ознакомление с бизнес-архитектурой заказчика перед внедрением ИС значительно ускоряет погружение сотрудников в проект и повышает качество конечного продукта.

Какие результаты, как правило, вы предоставляете заказчику?

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

Какие перспективы по развитию методик у Вас имеются?

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



Архив