На пресейлах представители клиентов достаточно часто меня спрашивают – расскажите, как ваша программа улучшит «жизнь» наших работников производства или склада или отдела закупок и т.п. Чаще всегда я стараюсь вежливо уйти от ответа на этот вопрос, сославшись на мировой опыт, лучшие практики и прочую маркетинговую чепуху. Но иногда я честно говорю, что не улучшит, а скорее для 90% пользователей жизнь станет хуже, а если проект завершится успешно, то некоторая часть из них, возможно, вообще потеряет работу, причем не по своей воле.
И дело тут не в том, что я предлагаю плохое программное решение, или у меня недостаточно опыта для его внедрения. Дело в том, что проекты бизнес-автоматизации – это совсем не про «счастье» рядовых пользователей.
Чтобы разобраться в этом парадоксе, давайте прикинем, зачем предприятие решает внедрить у себя новую информационную систему бизнес-автоматизации.
Что чаще всего присутствует в разделе целей проекта устава проекта автоматизации (я их видел несколько десятков, поэтому выборка вполне представительна):
- Повышение эффективности бизнеса.
- Сокращение трудозатрат на ведение учета.
- Создание инструментов для проактивного управления бизнесом (это самая изощренная формулировка, которая просто предполагает переход от посмертного «учета» к планированию своей деятельности).
Теперь давайте декомпозируем эти цели на задачи проекта автоматизации.
Повышение эффективности бизнеса предполагает, что бизнес на данный момент не эффективен или недостаточно эффективен с точки зрения его руководства/владельца.
Что такое неэффективность бизнеса, если говорить предметно:
- Это, например, излишки материалов/товаров на складе, которые со временем портятся и теряют цену. В процессе появления этих излишков были потрачены хорошие деньги, которым можно было бы найти лучшее применение.
- Или это невзысканные своевременно долги с покупателей, из-за которых образуются кассовые разрывы и потребность в привлечении кредитов, которые не дешевы.
- Или это складские потери или брак в производстве, который увеличивает себестоимость нашей продукции и снижает рентабельность бизнеса.
Но эти проблемы не возникли сами по себе – у каждой проблемы, зачастую, есть имя и фамилия – кто-то, например, неправильно спланировал закупки товара и создал неликвидные запасы. То, что эти запасы неликвидны, он знает из без средств «высокой» автоматизации – чтобы посчитать оборачиваемость запасов, чаще всего достаточно Excel и пары дней ненапряженной работы – загрузить в Excel остатки, посчитать оборачиваемость материала по году и прикинуть, на сколько сотен лет Вам хватит этой пищевой добавки, у которой максимальной срок годности полгода, и что с этим теперь делать.
Будет ли рад этот кто-то, если факт, что его ошибки стоят бизнесу хороших денег, станет известен широкому кругу лиц и руководству предприятия? Вряд ли.
Конечно можно сказать, что неэффективность управления бизнесом была вызвана тем, что раньше не было такой чудесной программы, а теперь «заживем» (Я почему раньше вредный был? Потому что у меня велосипеда не было). Но это тоже вряд ли случится само собой и при счастливом согласии участников проекта. И об этом следующие пункты.
Цель проекта «Снижение трудозатрат на ведение учета» – данный пункт предполагает, что в бизнесе есть лишние руки, которые создают эти дополнительные трудозатраты. От этих лишних трудозатрат мы хотим избавиться, внедрив программу.
Это значит, что этим лишним рукам, после внедрения программы, нужно будет найти новое применение, или нужно будет избавиться от них.
Я думаю, мало кого обрадует перспектива потерять работу, даже из самых благих побуждений повышения эффективности бизнеса – чужого бизнеса.
В мой практике, было несколько таких примеров, когда персонал понимал, что его работа будет не нужна после внедрения системы – в лучшем случае это были итальянские забастовки, в худшем – восстание луддитов – вряд ли это можно назвать «счастьем» для работника.
Ну и третья цель «Создание инструментов для проактивного управления бизнесом». Чаще всего это требует реорганизации бизнеса. А как выглядит реорганизация:
- Исследование того «как есть» сейчас.
- Анализ ситуации и выявление проблемных мест.
- Формирование концепции «как нужно».
- Реализация этой концепции на практике.
В перечисленных пунктах мы сразу наступаем на три любимые мозоли коллектива предприятия – во-первых проблемные места всегда имеют имя и фамилию (об этом я написал раньше, не буду повторяться), во-вторых исследование текущей ситуации на практике означает «засунуть свой нос в чужие дела» и отвлекать человека от его основной работы. Ну и в третьих, реализация новой концепции «как нужно» вполне может привести к образованию лишних рук из-за снижения трудозатрат по итогам оптимизации бизнес-процессов – последствия я уже обозначил.
То есть, в процессе выполнения нашего проекта, значительная часть пользователей окажется несчастной и будет всячески противодействовать внедрению новой ИТ системы, какая бы она хорошая не была. Поэтому меня очень веселят рассказы некоторых «молодых» специалистов, о том, что стоит только показать пользователям новую программу, рассказать о её преимуществах и они радостно понесутся вперед – в светлое будущее. На самом деле все выглядит совершенно иначе – небольшая группа замотивированных и лояльных людей противостоит большому коллективу раздражённых и озлобленных новшествами пользователей – и так было всегда и так будет всегда.
Что тут можно предложить – первое что приходит на ум – это активная пропаганда что «будет лучше, нужно лишь потерпеть». Это работает до определенного момента, причем со временем происходит эскалация пропаганды до степени обмана – когда ты отчетливо понимаешь, что человек, с которым ты сейчас беседуешь, скорее всего будет уволен по итогам, но для целей выполнения проекта тебе сейчас нужно его как-то убедить что-то сделать. Не очень хорошее решение, которое ведет к фрустрации и разочарованию в работе – ты вроде делаешь в целом хорошее дело, но местами ведешь себя как конченный подлец.
А теперь давайте вернемся к моему тезису «проекты бизнес-автоматизации – это совсем не про «счастье» рядовых пользователей». Это действительно так, потому что их реальными заказчиками являются не рядовые пользователи, а владельцы или ТОП-менеджмент предприятия. Которые заинтересованы в повышении эффективности бизнеса. Но при этом они могут вообще не быть пользователями внедряемого решения (за всю свою практику я видел только одного крупного босса, которые реально работал во внедряемой системе – у остальных для этого были подчиненные).
И вот этот факт полностью снимает все противоречия – мы работаем в бизнес-автоматизации не для того, чтобы делать пользователей счастливыми (это возможный приятный побочный эффект), а чтобы владельцы и/или руководители бизнеса были счастливыми – с этим постулатом нужно или сразу согласиться и смириться, или не заниматься бизнес-автоматизацией вообще, чтобы не заработать нервный срыв и получить профессиональное выгорание.
На моем жизненном пути было несколько очень хороших специалистов, у которых я многому научился, но которые не смогли смириться с этим – в итоге они или регулярно страдают от своей работы, или просто сменили вид деятельности. Честно сказать, я и сам не до конца с этим смирился, но в «розовых единорогов» счастливых проектов бизнес-автоматизации перестал верить давно.
Поэтому, если Вы руководитель проекта или специалист на проекте внедрения, и Вы регулярно чувствуете внутреннюю опустошенность от того, что вашу работу никто не оценивает по достоинству – Вы, скорее всего, не тех оценщиков выбираете – не работаете с теми, для кого этот проект фактически делается.
И вот теперь мы от пессимизма переходим к практике – один из самых успешных продавцов проектов комплексной бизнес-автоматизации, с которым я работал, высказал однажды очень важную идею – «Если на пресейле я не работаю с владельцем бизнеса или генеральным директором – это скорее всего будет неуспешный проект, в который вообще не стоит идти».
Если Вы хотите успешный проект и счастливого заказчика – забирайтесь на самый верх – как можно выше – именно там находятся благодарные потребители ваших услуг, которые Вас оценят и поддержат в трудную минуту. Но для того чтобы с ними договориться, нужно научиться разговаривать на языке бизнеса и согласиться с тем, что решения, принимаемые в рамках проекта, в первую очередь служат интересам ограниченного круга высокопоставленных лиц бизнеса, а остальное есть лишь следствие этого.
Несколько слов о «языке бизнеса» (достаточно заезженные термин, за которым зачастую пытаются скрыть какие-то маркетинговые вещи). Здесь все тривиально – цель бизнеса – это получение прибыли. Если Ваш проект служит этой цели – Вы уже априори разговариваете на этом языке, и нужно лишь детализировать эту цель до конкретных проектных решений, например:
- Создадим удобный АРМ для диспетчера транспортного цеха, который позволит оперативно готовить отгрузочные документы на маршрут, что приведет к сокращению простоя транспорта на погрузке, что позволит нам платить меньше перевозчикам, что позволит сократить расходы = рост прибыли.
- Создадим отчет для анализа оборачиваемости запасов на складе, что позволит исключить появление неликвидных запасов ТМЦ, что позволит высвободить оборотные средства и сократить расходы на привлечение внешних заимствований = рост прибыли.
- Создадим отчет для анализа «спящих» клиентов, что позволит оперативно их обзванивать и увеличить объем продаж = рост прибыли.
Все достаточно просто – Вы занимаетесь бизнес-автоматизацией – ваши решения влияют на эффективность бизнеса – Вы должны доносить эту информацию до правильного заказчика и тогда всё у Вас будет хорошо – максимально хорошо в рамках конкретного предприятия. Заказчик (руководитель) сам будет «продавливать» непопулярные решения и «строить» пользователей – Вам нужно лишь своевременно и адекватно объяснить ему эффект от этих решений. При этом количество возможной «несправедливости» в отношении отдельных сотрудников не уменьшится, но по крайней мере этим вопросом будет заниматься тот, кому это положено по должности или положению. А если Вы и с этим не готовы мириться, то Вам действительно стоит подумать о смене направления работы – это не ваше.
Есть правда и обратная сторона – некоторые специалисты ИТ так проникаются идеей что работа делается не для пользователей, что пользователи воспринимаются как личные враги, которых нужно специально ущемлять. Это тоже неправильный подход к работе – к пользователям нужно относиться по справедливости – тех, кто Вам лоялен, нужно поддерживать, с теми, кто Вам противодействует, предметно работать через их руководство, тех, кому все равно, своевременно загружать нужной Вам по проекту работой и контролировать её исполнения. Это все-таки проект автоматизации, а не ваша личная вендетта несовершенному человечеств. В противном случае Вам также грозит профессиональное выгорание.
И последнее, что хотелось бы сказать: иногда таких заказчиков у Вас вообще не будет – предприятия из крупных холдингов зачастую управляются наемными менеджерами, которые теоретически хотят внедрить модную программу, но не осознают объем необходимых усилий с их стороны для выполнения подобного проекта. Это тоже нужно уметь оценивать, чтобы вовремя решить – захотите и сможете ли Вы в одиночку реорганизовать целый завод или лучше вовремя отступить, прикрывшись формальными причинами. Об этом будет моя следующая статья.
