Работа консультанта по изменениям, а сейчас и членство в жюри конкурса проектов по автоматизации однозначно свидетельствует о том, что не боги горшки обжигают. Автоматизация может быть успешной и тогда, когда делается силами самой компании, и когда для этой цели приглашаются аутсорсеры. И, к сожалению, она может оказаться неуспешной как в первом, так и во втором случае.
Встает вопрос: так в чем же залог успешности автоматизации бизнес-процессов? Отрефлексировав свой опыт, можем сказать, что и компетентность заказчиков, и опыт, и обязательность исполнителей, и вовлеченность руководства – все это необходимо для успешности проекта. Но еще важна и технология, простая и примитивная пошаговая технология продвижения. Сейчас модно говорить об Agile или о Scrum как о том, что вновь появилось на горизонте управления. Однако эти «новинки» являются таковыми лишь для сферы IT, но не для управления изменениями, где и работа в малых группах на общий результат, и постоянные встречи с заказчиком, чтобы сверить часы, и распределенные роли – давно известные моменты. Именно поэтому хочется еще раз напомнить о том, какой же должна быть технология работы по автоматизации бизнес-процессов, которая есть лишь частный случай общего подхода к управлению изменениями.
Шаг 1. Диагностика существующего положения дел
В IT этот этап называется «анализ as is». Результатом этапа должно стать понимание со стороны заказчика и исполнителя, какую часть бизнес-процесса (БП) предстоит автоматизировать. И здесь, конечно же, должны появиться цели по времени, по эффекту, по тем параметрам, которые предстоит улучшить в результате процесса автоматизации. Тут же появляется график и бюджет проекта, распределяются роли его участников. Появляется руководитель проекта, который будет отвечать за намеченные результаты. Кстати, крайне редко эффективными руководителями проектов оказываются айтишники. И самые мудрые из них предпочитают выбирать для себя роль исполнителя, отдавая ответственность за проект руководству компании или бизнес-заказчику.
Шаг 2. Формирование образа будущего
На этом этапе изучается бизнес-процесс «to be» – каким он должен стать. И вот возникает засада: программисты некомпетентны, чтобы сказать, каким должен быть бизнес-процесс. Чтобы это определить, необходимо привлекать либо бизнес-аналитиков, либо использовать компетенции людей бизнеса, бизнес-заказчиков, опыт которых позволяет это сделать. Однако, как показывает практика, в компаниях часто отсутствует и та экспертиза, и другая. И если руководство компании доверяется в этот момент только программистам, проект, скорее всего, будет провален.
Шаг 3. Согласование образа «to be» с подразделениями компании
В первую очередь речь идет об автоматизации тех бизнес-процессов, которые затрагивают несколько подразделений компании, если не все сразу. Даже автоматизация такой простой функции как оформление командировки – и то предполагает участие бухгалтерии, отдела кадров и бизнеса. Что уж говорить о внедрении складских систем или систем управления клиентскими отношениями. Именно на этом этапе рабочие группы становятся основным средством работы. Разнопрофильные команды собираются для обсуждения видения будущего бизнес-процесса, согласуя свои представления о том, каким он должен стать.
Шаг 4. Программирование
Написание программных кодов, как это ни звучит парадоксально, – самый простой процесс в этой работе. Главное, чтобы была правильно поставлена задача, под которую IT-специалисты составляют алгоритм – как повара готовят еду, а машинист ведет поезд. Безусловно, чем грамотнее и опытнее эти люди, тем быстрее они сделают продукт, который можно будет тестировать в реальном процессе.
Шаг 5. Подготовка людей к работе по-новому
Этот этап целесообразно начинать одновременно с четвертым этапом. Осуществляя его, важно понимать, что те, чью работу автоматизируют, испытывают два вида страхов: страх появления нового инструмента и страх быть уволенным в результате его внедрения. Оба эти момента вызывают дикое сопротивление у людей, с которым надо работать. Обучение персонала поможет снять страхи первого рода, поэтому тут надо только предусмотреть время, чтобы заранее начать это делать. Что же касается боязни увольнения из-за ненужности, то тут придется попыхтеть менеджерам, чтобы сохранить мотивацию тех сотрудников, которые им нужны, и облегчить уход тем, с кем предстоит расстаться.
Шаг 6. Тестирование продукта
Во-первых, крайне настоятельно рекомендуем делать в несезон. Ведь у каждого бизнеса есть свои пики активности, которые плохи для проведения испытаний любого рода. А, во-вторых, тестирование стоит проводить на ограниченном поле – участке, ассортименте, категории клиентов. Нет смысла сразу все переводить на новые рельсы, потому что в ходе тестирования неизменно появятся моменты, которые надо исправить и откорректировать.
Шаг 7. Запуск в эксплуатацию
Это вершина работы. Когда все знают, что новый бизнес-процесс выстроен и отлажен, что люди научились с ним работать, что поставленные исходно цели однозначно выполнены.
Известно, что только 30% проектов по автоматизации завершаются успешно, что, конечно же, крайне печально. Потому что ресурсов они отнимают у бизнеса немерено, а главное – разрушают надежду на «чудо автоматизации»: будет одна кнопка, и я смогу все видеть, делать, контролировать. Да, в российском бизнесе сегодня часто приходится сталкиваться с ожиданием этого чуда. Однако, по нашему мнению, чем быстрее наступит понимание того, что автоматизация не цель, а средство, инструмент, который еще надо сделать эффективным, чтобы он заработал, чем раньше бизнес-заказчики поймут, что никто за них ничего не придумает – тем меньше ресурсов бизнеса будет тратиться впустую.
Фото: pixabay.com
статья о том что Волга впадает в Каспийское море с элементами дилентанства
Ну да, очевидные вещи, хотя, похоже, это действительно не все понимают
Извиняюсь, какой график получится, если объем проекта еще не известен? Ведь объем работ станет известен после сравнения "как есть" и "как надо". И Руководителя Проекта нужно бы назначить сразу же, как только принято полномочное решение о запуске проекта, и до начала любых проектных дел и забот.
соглашусь с Сергеем Левицким - план и бюджет проекта возможно сделать только после анализа as is и to be. И да - РП нужен сразу же.
Шаг 4 - у автора устаревший взгляд на автоматизацию БП. При нынешнем уровне систем WorkFlow это уже не программирование, а настройки.
И да - здесь лучше привлекать внешнюю компанию с готовыми скилзами.
Вообще, описанный подход скорее всего приведёт к неудаче, потому как делается разными командами. Как раз тут такой случай когда Agile вам в помощь. Должна быть единая команда проекта с участием бизнеса, ИТ-службы, внешнего подрядчика.
Этот абзац чисто "мнение эксперта". Очень правильно в этом форуме очень давно написал Тимур Кадыев - это действительно эксперт в проектировании бизнес-процессов. Основное отличие специалистов по проектированию бизнес-процессов и программистов (в т.ч. бизнес-аналитиков вышедших из программистов) состоит в том, что первые занимаются проектированием бизнес-процессов "сверху вниз", а вторые "снизу в верх".
Если речь идёт об эволюционной доработке, то я бы больше доверял вторым - программистам компании - у них опыт и реальные знания о бизнесе. Если требуются серьёзные изменения бизнес- процессов, то первым. Но беда в том, что собственных специалистов обычно просто нет, а проекты сторонних специалистов как правило остаются на "бумаге", потому что встречают внутренне сопротивление или по многим другим причинам. Покупка западного софта - со всеми их "бест практикс" :) оказывается в очень многих случаях ещё более худшим решением - кроме всего прочего теряются наработанные конкурентные преимущества, при использовании "чужих" бизнес-процессов.
Доверяйте чаще выбор решения своим работникам, и у Вас получится!
Поставил +1 за смелость. Удачи Вам, Светлана. Делитесь опытом и ничего не бойтесь. Появится системный подход.
Такие статьи были очень модны лет 15 назад. Даже заголовки похожи.
Но печально, на мой взгляд, следующее.
Очень печальная динамика усвоения опыта прошлого. Мы вернулись ровно туда, откуда начал движение эти 15 лет назад. И снова обсуждаем одно и тоже. И снова опровергаем опровергнутое. И вдруг становится ясно, что за эти 15 лет даже молодые и креативные так и не поняли ни сути программирования, ни сути методологий внедрения. За 15 лет ни высшая система образования, ни ЕГЭ, ни МБА не смогли стабилизировать понимание программирования, автоматизации бизнес-процессов. Печально, господа!
Философы учат, что вся диалектика соответствует спирали. Они правы. Но мы открываем новый тип диалектической спирали, у которой чрезвычайно малый шаг. Как у склерозника, для которого каждый день новости.
Общий менеджмент не берет на себя автоматизацию. Кто добровольно возьмет на себя новую обязанность?
Я правильно понимаю, что речь в статье идёт о "тупой" автоматизации? Ну, то есть никакого улучшения(оптимизации) механизируемого процесса не предполагается? Просто, если под этим соусом автор пытался продать оптимизацию, я готов еще сто минусов статье поставить...
Как я понял, с точки зрения статьи оптимизация по дефолту входит в автоматизацию.
На пушечный выстрел таких "менеджеров" нельзя подпускать к оптимизации, с такими тезисами и подготовкой ((( Книжки хоть почитайте, по оптимизации-то, "as is даёт картину что автоматизировать", шедевр, блин. Я уж молчу о том, что делать софт, с заточкой под разовую оптимизацию процессов... не будем о грустном.