Работа консультанта по изменениям, а сейчас и членство в жюри конкурса проектов по автоматизации однозначно свидетельствует о том, что не боги горшки обжигают. Автоматизация может быть успешной и тогда, когда делается силами самой компании, и когда для этой цели приглашаются аутсорсеры. И, к сожалению, она может оказаться неуспешной как в первом, так и во втором случае.
Встает вопрос: так в чем же залог успешности автоматизации бизнес-процессов? Отрефлексировав свой опыт, можем сказать, что и компетентность заказчиков, и опыт, и обязательность исполнителей, и вовлеченность руководства – все это необходимо для успешности проекта. Но еще важна и технология, простая и примитивная пошаговая технология продвижения. Сейчас модно говорить об Agile или о Scrum как о том, что вновь появилось на горизонте управления. Однако эти «новинки» являются таковыми лишь для сферы IT, но не для управления изменениями, где и работа в малых группах на общий результат, и постоянные встречи с заказчиком, чтобы сверить часы, и распределенные роли – давно известные моменты. Именно поэтому хочется еще раз напомнить о том, какой же должна быть технология работы по автоматизации бизнес-процессов, которая есть лишь частный случай общего подхода к управлению изменениями.
Шаг 1. Диагностика существующего положения дел
В IT этот этап называется «анализ as is». Результатом этапа должно стать понимание со стороны заказчика и исполнителя, какую часть бизнес-процесса (БП) предстоит автоматизировать. И здесь, конечно же, должны появиться цели по времени, по эффекту, по тем параметрам, которые предстоит улучшить в результате процесса автоматизации. Тут же появляется график и бюджет проекта, распределяются роли его участников. Появляется руководитель проекта, который будет отвечать за намеченные результаты. Кстати, крайне редко эффективными руководителями проектов оказываются айтишники. И самые мудрые из них предпочитают выбирать для себя роль исполнителя, отдавая ответственность за проект руководству компании или бизнес-заказчику.
Шаг 2. Формирование образа будущего
На этом этапе изучается бизнес-процесс «to be» – каким он должен стать. И вот возникает засада: программисты некомпетентны, чтобы сказать, каким должен быть бизнес-процесс. Чтобы это определить, необходимо привлекать либо бизнес-аналитиков, либо использовать компетенции людей бизнеса, бизнес-заказчиков, опыт которых позволяет это сделать. Однако, как показывает практика, в компаниях часто отсутствует и та экспертиза, и другая. И если руководство компании доверяется в этот момент только программистам, проект, скорее всего, будет провален.
Шаг 3. Согласование образа «to be» с подразделениями компании
В первую очередь речь идет об автоматизации тех бизнес-процессов, которые затрагивают несколько подразделений компании, если не все сразу. Даже автоматизация такой простой функции как оформление командировки – и то предполагает участие бухгалтерии, отдела кадров и бизнеса. Что уж говорить о внедрении складских систем или систем управления клиентскими отношениями. Именно на этом этапе рабочие группы становятся основным средством работы. Разнопрофильные команды собираются для обсуждения видения будущего бизнес-процесса, согласуя свои представления о том, каким он должен стать.
Шаг 4. Программирование
Написание программных кодов, как это ни звучит парадоксально, – самый простой процесс в этой работе. Главное, чтобы была правильно поставлена задача, под которую IT-специалисты составляют алгоритм – как повара готовят еду, а машинист ведет поезд. Безусловно, чем грамотнее и опытнее эти люди, тем быстрее они сделают продукт, который можно будет тестировать в реальном процессе.
Шаг 5. Подготовка людей к работе по-новому
Этот этап целесообразно начинать одновременно с четвертым этапом. Осуществляя его, важно понимать, что те, чью работу автоматизируют, испытывают два вида страхов: страх появления нового инструмента и страх быть уволенным в результате его внедрения. Оба эти момента вызывают дикое сопротивление у людей, с которым надо работать. Обучение персонала поможет снять страхи первого рода, поэтому тут надо только предусмотреть время, чтобы заранее начать это делать. Что же касается боязни увольнения из-за ненужности, то тут придется попыхтеть менеджерам, чтобы сохранить мотивацию тех сотрудников, которые им нужны, и облегчить уход тем, с кем предстоит расстаться.
Шаг 6. Тестирование продукта
Во-первых, крайне настоятельно рекомендуем делать в несезон. Ведь у каждого бизнеса есть свои пики активности, которые плохи для проведения испытаний любого рода. А, во-вторых, тестирование стоит проводить на ограниченном поле – участке, ассортименте, категории клиентов. Нет смысла сразу все переводить на новые рельсы, потому что в ходе тестирования неизменно появятся моменты, которые надо исправить и откорректировать.
Шаг 7. Запуск в эксплуатацию
Это вершина работы. Когда все знают, что новый бизнес-процесс выстроен и отлажен, что люди научились с ним работать, что поставленные исходно цели однозначно выполнены.
Известно, что только 30% проектов по автоматизации завершаются успешно, что, конечно же, крайне печально. Потому что ресурсов они отнимают у бизнеса немерено, а главное – разрушают надежду на «чудо автоматизации»: будет одна кнопка, и я смогу все видеть, делать, контролировать. Да, в российском бизнесе сегодня часто приходится сталкиваться с ожиданием этого чуда. Однако, по нашему мнению, чем быстрее наступит понимание того, что автоматизация не цель, а средство, инструмент, который еще надо сделать эффективным, чтобы он заработал, чем раньше бизнес-заказчики поймут, что никто за них ничего не придумает – тем меньше ресурсов бизнеса будет тратиться впустую.
Фото: pixabay.com
А мне кажется, нормальная статья.
А в каком смысле делать софт под разовую оптимизацию процессов? Софт, наверное, всегда требует логичного бизнес-процесса, потому что сам работает по логике. Если процессы нелогичные, конечно, приходится оптимизировать, чтобы перейти на автоматизацию. Другое дело, что оптимизировать процессы лучше и так, а потом более "втупую" автоматизировать то, что логично работает.
Но часто получается, что сначала менеджеры решают автоматизировать работу, а по ходу проекта оказывается, что процесс не автоматизируется, и его нужно либо срочно оптимизировать, либо писать "костыли", либо оставлять отдельные участки без автоматизации.
Не-а, не нормальная, объясню почему.
1.Пока не "вылизан" to be с точки зрения бизнеса, вообще никакой ИТ не нужен - смысл потенциально выбрасываемое ковырять?
2. Процессы не "нелогичные", процессы или есть и непротиворечивы, или функциональный бардак.
3. Софт ничего не "требует", ещё чего не хватало. Софт - обеспечивает функциональность. Наличие непротиворечивого процесса даёт гарантию возможности повторения его в виде кода.
4. Легко автоматизировать отдельную функцию, тяжело софтом "поймать" весь процесс. Особенно, когда понимаешь суть термина "экземпляр процесса".
5. После отрисовки процесса оптимизация только начинается, если софт не снимает никаких метрик, дальнейшая считай что провалена (а тут шаг 7 - это финиш).
Поэтому, выглядит статья как набор нелепых телодвижений в рамках функциональной модели, в которой непонять зачем приплели процессы. Модно, чё. А начинать автоматизацию в надежде что и оптимизацию "нахаляву" получим - глупее не придумаешь ))) на самом деле эффективнее наоборот делать.
Про "разовую" - раз шаг 7 - финиш, дальше никто никогда копать не думал. Значит, дальнейшим оптимизациям каюк. Тут даже про контроль достигнутого и анализ ни слова (п.4 выпал), верный признак что не за оптимизацию бьёмся.
Светлана, так на мой взгляд вы не поняли суть Agile и Scrum. Это вовсе не революционные методологии проектного управления (как их продают). Это признание капитуляции в той самой ситуации, которую вы описываете.
Да, теоретически правильные подходы не работают, как не работает и ваш. Точнее - есть небольшой шанс (на практике не больше 20-25%) - что "что-то в итоге получится" - в том числе и при том подходе, что описали вы.
Но это означает, что успешным окажется скорее всего 3-4 внедрение - когда в процессе предшествующих компания наберётся опыта и будет представлять чего она хочет и главное - чего и как делать не надо.
Ровно так и происходило в реальной жизни - и не один раз. Примеров много - достаточно посмотреть на внедрения SAP в ТНК BP, X5 Retail Group и множестве других компаний или кучу проектов "корпоративных порталов".
Так вот в какой-то момент просто сообразили и подсчитали, что если делать внедрение по гибкому подходу (то, что продаётся как Agile) стоит почти в два раза дороже обычного - но это в полтора-два раза дешевле, чем оплата 3-4 внедрений.
То есть по факту работать по схеме Time & Material (просто оплачивая рабочие часы исполнителя) - что казалось нонсенсом ещё недавно, вовлекая сотрудников заказчика в процесс (Agile) - оказалось в конечном итоге банально выгоднее...Вот это и есть практическое решение - и как показала жизнь - второе работающее на практике и более эффективное чем оплата 3-4 внедрений, на которых компания учится внедрять.... ;-)
Других путей и каких-либо магических фокусов на практике просто не существует. И те истории, когда кому-то удалось нечто внедрить в первого раза по факту лишь исключения, подтверждающее правило. Так как повторить фокус не удаётся. ;-)
или покупка какой-нибудь западной системы. Покупают первую - не получилось, потом меняют на вторую, третью ...
Только Agile подходы далеко не новые - уже третий десяток лет разменяли.
Есть вариант дешевле для конкретных предметных областей: Платформа пишется используя классический водопад + / или XP (Extreme Programming). Потом все внедрения новых разработок под конкретного Заказчика только используя XP.
Например, если написана платформа для управленческого учёта, потом можно быстро достроить систему под конкретного заказчика в его предметной области. Особенно помогают шаблоны проектирования, для поддержки такого метода работы.
Так это и есть внедрения - чей софт не важно. Это может быть одна система (как SAP в ТНК BP) или разные - суть это не меняет. Есть примеры, когда откровенно уступающие системы внедрялись удачно - просто потому что компания к моменту внедрения именно этой системы набиралась опыта и внедрение оказывалось успешным. И потом, в результате, они долго и мучительно с этой системы переходили на другую ... лет 5. ;-)
Согласен, но по сути это лишь вариации и оптимизации из той пары подходов которые я описал. Ведь в чистом виде Agile - это когда мы вообще не представляем чего хотим и начинаем код писать - на практике встречается ещё реже, чем такой же чистый водопад.
Чаще всего в том или ином виде некое представление и каскадный план так или иначе есть. Он используется для оценки бюджета, сроков, формирования ожиданий, КП, ТЗ, и, конечно, оптимизации. А уж как писать код - используя XP, TDD, BDD, SCRUM, Agile, Lean, Kanban или их творческую вариацию дело десятое...
Обычно это является важным лишь в том случае, когда квалификация команды не очень высока и/или процесс организован откровенно неудачно - не хватает каких-либо элементов, которые должны быть, и/или есть узкие места. И чаще всего это проектирование, QA и инфраструктура - особенно для QA/тестирования.
Но это уже другая проблема - скорее производственная. Из серии - сначала экономят на проектировании, тестах и инфраструктуре, чтобы "подешевле было", а потом, когда люди 70-80% времени тратят на исправление ошибок и выпуск релизов, сроки едут а счастье так близко - чистосердечно раскаиваются...
Ну так и есть, но на практике компании могут чуть ли не годами работать на потенциально выбрасываемых процессах и писать для них программные "костыли"))
Придираетесь к словам. По сути это у меня и было написано
Опять зря придираетесь. Процессы именно нелогичные - т.е. не могут быть формализованы с использованием логики в самом прямом смысле этого слова.
Тут то же самое, что в первом абзаце - теоретически правильно, но на практике такой подход уже за основу взяли.
По этому и остальным пунктам понятно
Не зря. Я считаю, что отрисовал/отсмотрел достаточно разноплановой деятельности, описанной в виде моделей, чтобы утверждать, что если деятельность нельзя формализовать - там точно царит бардак и о "процессе" говорить не приходится. Вот если можно - то да, какая-никакая, но стабильность есть,и можно переходить к оптимизации.
Слышится обречённость в слове "уже" ))) Да, есть такой момент, от общей безграмотности, но есть и компании, где сначала на орг.изменения навалились. Рост выручки и почти вертикальный график прибыли - неплохой приз за вменяемость )))
Еще бы их не было. Вопрос в средней по статистике)
нелогичный (неформализуемый) процесс - не процесс?