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