Светлана Гацакова, директор департамента корпоративных информационных систем ALP Group
Сегодня высокая адаптивность к потребностям различных категорий потребителей, действиям конкурентов, развитию технологий, появлению перспективных управленческих идей и, соответственно, методик менеджмента – это обязательное требование к бизнес-процессам предприятий и к интегрированным системам управления ими. Это не преувеличение, а реальность. При нынешнем потоке изменений, в котором живет и действует современное предприятие, неадаптивная система автоматизации управления, как правило, «умирает» еще в процессе внедрения или вскоре после начала эксплуатации. Предприятиям самое время пристально присмотреться к двум методикам, позволяющим существенно снизить остроту ситуации. Это гибкое управление проектами внедрения (Agile project management) и устранение дефектов и шероховатостей в системе процессов (process mining)
Конечно же, в настоящее время даже в самых передовых компаниях число сторонников и противников применения этой методологии управления делится примерно поровну. Тем не менее, я уверена, что данный подход к управлению пора предлагать заказчикам и широко применять в проектах, так как у него есть весомые плюсы. В этом утверждении я опираюсь на опыт нашей компании, которая уже несколько лет на равных использует Agile как промышленную методику внедрения сложных ERP-решений на крупных предприятиях. Среди плюсов Agile, послуживших толчком к переходу от экспериментов к промышленному применению данного подхода в нашей компании, отмечу следующие:
Так как есть спринты[1]. Это короткий повторяющийся цикл разработки (спринт не обязательно должен занимать две недели), который каждый раз создает какой-то ценный для заказчика результат. Например, за две недели разработчики выполняют определенные доработки и выдают клиенту готовый результат (встроенный в продуктивную систему, а не в какой-то прототип). Для сравнения: если работы выполняет методолог, то приходится ждать конца проекта, то есть результаты могут появиться, например, через год. А благодаря спринтам заказчик постоянно видит поток «маленьких результатов», благодаря которому повышается скорость «доставки» готового продукта или решения и возникает эффективная петля обратной связи, влияющая на дальнейшее развитие системы.
То есть, заказчик при появлении каких-то новых бизнес-задач, может быстро внести их в план разработки, поменяв местами с менее приоритетными задачами.
Сама суть этой методологии состоит в том, что на регулярной основе (с периодом, равным длине спринта) проходят совещания всей рабочей группы, идет тесное общение с клиентом, включая его консультирование, коррекцию представлений о его потребностях, уточнение того, поменялось ли вообще его видение и в какую сторону. А это позволяет в кратчайшие сроки поменять свои планы разработки и получить соответствующие результаты уже в конце очередного спринта.
Команда разработчиков выступает также в роли консультантов. И помогает заказчику определить, что будет действительно нужно, а что не так важно, какие выгоды он сможет получить от внедрения того или иного элемента. И, опираясь на полученную информацию, на постоянной основе контролировать и видоизменять состав тех задач или элементов, которые будут разрабатываться или внедряться в дальнейшем.
Ведь команда всегда видит определенную конечную цель и на этом фоне видит свой результат. Это особенно важно для разработчиков, которым необходимо понимать конечную цель выполнения своей работы. Для сравнения: при обычном методе разработки, в проекте длительностью 1,5 года часто бывают ситуации, когда разработчик вообще не видит конечный результат, утрачивает смысл своей работы, «варится в своем соку» на протяжении полугода – и при этом его особо никто не трогает. При использовании Agile такого просто не может быть: на регулярных SCRUM-митингах команда рассказывает, что сделано, что планируется делать дальше, какие результаты получены. Конечные результаты оказываются на поверхности, открыто обсуждается, что получилось и как это повлияет на бизнес. Всё это очень важно в том числе для управления ресурсами, для взаимодействия с командами, включая и HR. Рост вовлеченности людей даёт вполне ощутимые результаты: снижается риск «оттока» ресурсов, находит выход недовольство и заблуждения, повышается лояльность сотрудников своей компании. Другими средствами получить эти результаты крайне сложно, а в Agile они являются естественным побочным эффектом способа организации работ.
В своей практике мы применяем такой метод управления как SCRUMна проекте с одним из ключевых заказчиков. Это позволяет лучше управлять его ожиданиями и улучшить качество выходного продукта».
Помимо SCRUM, мы применяем и метод Kanban. Так, с его помощью на одном из наших проектов мы визуализировали все выполняемые командой задачи. Это позволило команде видеть перспективу: какие задачи планируется выполнить, какие задачи разрабатываются, какие находятся на стадии тестирования и какие уже выпущены в релизе. Таким образом, все понимают, каково реальное продвижение проекта, какие задачи «зависают» и на какой стадии. А это, в свою очередь, позволяет увидеть насколько эффективно работают те или иные специалисты, где возможен срыв планов (например, сроков выпуска очередного релиза) и недовольство заказчика. То есть, данный метод из арсенала Agile позволяет своевременно выявить реально существующие «узкие места» – и оперативно отреагировать на них, не дав проекту «вывалиться из графика». Здесь очень помогает то, что четко видна ответственность конкретного сотрудника за конкретную область работ.
Хочу подчеркнуть, что переход на Agile требует перестроения не только внутри своей проектной команды, но также требует проявить какой-то консалтинг и помочь перейти на этот метод и конечному заказчику. Ведь он становится таким же полноправным участником Agile-методологии, и ему приходится перестраивать свои процессы. От заказчика также требуется больше вовлеченности в проект, он уже не ожидает окончания всего проекта, а постоянно спрашивает: «где результат?» Ответственные сотрудники заказчика должны участвовать в регулярных SCRUM-митингах, четко понимая их место в системе управления проектом, формат этой встречи, распределение ролей участников и свою ответственность за результат. И мое мнение, что для такого перехода на данном этапе развития рынка очень важно выделить, так называемого agile-коуча, который позволит заказчику безболезненно перестроиться на работу по новой для него методологии Agile, причем в кратчайшие сроки. И конечно же, самое главное, контролировать и получить подтверждение от заказчика, что этот переход действительно произошел гладко и что заказчик понимают перспективы и выгоды.
Но при этом, я все-таки считаю, что сегодня Agileеще нельзя применять в управлении особо сложными проектами, от которых зависит какая-то сложная инфраструктура, потому что в этих проектах есть четкая стоимость, которую нельзя варьировать
Также этот подход не имеет смысла применять в малых организациях, где численность сотрудников не достигает 50-ти человек.
Это методология управления практически любыми формализованными процессами организации, позволяет выявить и устранить ошибки и дефекты проектирования. Это особенно актуально для отечественных предприятий, которые не имеют многолетней практики работы в рамках процессной организации. Но чтобы она заработала, нужны эффективные ИТ-инструменты. Мы, например, разработали собственное ИТ-решение, которое позволяет в соответствии с разными критериями анализировать эффективность бизнес-процессов, выполняющихся в компании. То есть, эта система может считывать все бизнес-процессы, проходящие «сквозь» компанию, сравнивать их с эталонными моделями этих процессов (с тем, как они были изначально спроектированы), выявлять и анализировать отклонения. И на этой основе – проводить пошаговое повышение эффективности и многокритериальную оптимизацию этих бизнес-процессов.
Например, изначально мы считали, что идеальный процесс должен состоять, допустим, из 5 шагов. Далее с помощью разработанной системы мы установили, что фактически в нашей компании выполнение этого процесса занимает не 5 шагов, а 15. Соответственно, у нас сильно повышается потребление ресурсов, необходимых для выполнения этого процесса, растет число вовлеченных в него людей, сильно увеличивается время (одно дело пройти 5 шагов, а 15 – это уже совсем другое). Это означает, что повышаются такие риски, как, например, утечка информации или приобретение и закрепление негативного опыта взаимодействия клиента с компанией. И система позволяет очень быстро понять, каким должен стать оптимальный процесс, свободный от выявленных недостатков.
Могу с уверенностью сказать, что применение этой методологии позволяет быстро и весьма существенно снизить практически любые риски, связанные с процессами, включая экономические, репутационные и связанные с лояльностью клиентов. Это позволяет значительно повысить эффективность всей системы процессов, ускорить процессы, к которым мы применяем processmining, снизить требования к ресурсам, задействовать меньше сотрудников и меньшее количество систем.
Сегодня внедрение и применение processminingкрайне важно для крупных компаний, особенно тех, которые торгуются на бирже или проходят внешний аудит. Ведь для них существует множество дополнительных требований, закрепленных различными регламентами, законодательством, руководящими документами различных регуляторов или бирж. Для этих компаний крайне важно постоянно поддерживать свои процессы в оптимальной форме, все время анализировать их и стараться повышать их эффективность.
Методологию process mining необходимо предлагать заказчикам. Сразу найти оптимальные алгоритмы всевозможных процессов, обеспечивающих идеальную работу крупной организации в постоянно меняющейся среде, – невозможно. Именно process mining позволяет перевести эту ситуацию из разряда фатальных в разряд рабочих, когда определенный набор методик и инструментов за небольшое число шагов приводит к результату, который нельзя получить другими способами.
Затраты компании на внедрение подобного подхода или соответствующих IT-решений, многократно оправдываются в дальнейшем. И станет одной их наиболее эффективных инвестиций в информационные технологии из всех, которые возможны
[1] Здесь я говорю о методике SCRUM, в которой удачно сочетаются гибкость и свобода, с одной стороны, и четкая процедурность – с другой.