Когда на предприятии затевается внедрение информационной системы, особенно силами внешнего подрядчика, то почти всегда говорится: самое большое препятствие – это люди. Сама система, кодирование нового функционала, обучение – это просто трудозатраты. А вот преодолеть саботаж внедрения, переломить мышление, особенно руководителей, заставить выйти из зоны комфорта старой системы (даже если она ужасна) – это действительно трудно. Причем, внедренцы обычно говорят: основная работа по «изменению людей» должна лежать и лежит на заказчике.

Реальную необходимость во внедрении системы оставим в стороне, она не является предметом обсуждения данного материала – считаем, что система действительно нужна. Внедрение идет по всем канонам, с техническим заданием, функциональными требованиями, планом-графиком и т.д. Ключевой критерий успешности проекта – реализация всех требований заказчика. Такой критерий вполне вписывается в методику оценки качества, которое есть степень соответствия требованиям потребителя. И вот система внедрена.

В ней есть все нужные объекты – документы, справочники, отчеты, формочки, интеграция. До, или после, или в процессе у нас появляется сайт, портал для работы с поставщиками, CRM-система, MDM-система, PLM, PDM, MES и т.д. И все это интегрировано между собой в необходимой степени. Все системы удовлетворяют требованиям компании, зафиксированным на момент внедрения. Грубо говоря, перед нами – снапшот компании в информационном поле. Ну разве не прелесть?

С точки зрения внедренцев – прелесть, еще какая. Акты подписаны, деньги получены, прекрасный лестный отзыв на фирменном бланке написан и проштампован. С точки зрения внутренних руководителей проектов внедрения – тоже прелесть. Премия получена, почет и уважение в кармане, может и должность подросла, а то и зарплата. Но тут происходит неприятность – бизнесу потребовались изменения. Когда объектом изменений является замена старой информационной системы на новую, все понятно. Это большой проект, длиной в несколько месяцев, а то и лет. Это – длинные изменения, с крупными инвестициями, они должны быть долгими, с высокой долей бюрократии, масштабом и множеством задействованных лиц. А если изменения – небольшие (с точки зрения бизнеса)?

Например, есть у нас система управления закупом, работает очень просто – из плана продаж на период формируется план закупок на тот же период. Разумеется, план закупок готов несколько раньше, чтобы успели закупить длинные позиции. И вот директор по закупкам решил, что закупать по плану продаж – прошлый век, да и реальность это подтверждает – постоянные дефициты, простои продаж и производства из-за срыва поставок. Теперь закупки будут работать по методу барабан-буфер-канат, который из Теории ограничений систем.

С точки зрения директора по закупкам, да и с обывательской, изменение простое, плюнуть и растереть. План продаж известен, динамика продаж известна, скорость отгрузки по каждой позиции известна (сколько штук отгружается, например, за месяц), время пополнения известно (количество дней от заказа у поставщика до поступления на склад). Просто выкидываем план закупа, и заменяем его целевым уровнем. Раньше в плане продаж было написано «купить 100 втулок», теперь в целевом уровне написано «поддерживать запас в 40 втулок на складе». Вместо работы месяцами, теперь надо работать каждый день, причем по очень простой математике: смотришь, сколько втулок на складе, добавляешь количество уже заказанных поставщикам – если получилось меньше 40, заказываешь недостающее количество. Все.

На объяснение закупщикам новой методики работы уходит пара часов, включая мотивационную часть (объяснение, зачем это нужно). Тут же начинается работа с поставщиками – им надо объяснить, что мы теперь будем заказывать не большими партиями, а маленькими, с динамически меняющимся размером. Кто-то из поставщиков встает в позу, мол у меня такты производства, и есть минимальная партия запуска. Ок, если поставщик ключевой – делаем целевой уровень равным его минимальной партии, т.е. не заказываем по 5 штук, а ждем, пока дефицит достигнет 50, и тогда заказываем. Это не очень хорошо, т.к. на складе будет лежать больше, чем нужно, но методика такое развитие событий вполне допускает. Если поставщик – не ключевой, и позиция не редкая, запускаем в фоновом режиме поиск новых поставщиков.

Все, счастье близко. Дефицитов не будет, простоев не будет, неликвидов не будет, запасы на складе (= замороженные деньги) снизятся. Что дальше? Автоматизация, будь она неладна. Нельзя же все расчеты вести на коленке?

Директор по закупкам идет к ИТ-директору, рассказывает об изменениях, просит автоматизировать. ИТ-директор закатывает глаза, и начинает причитать о том, как долго они автоматизировали предыдущую схему, как хорошо она работала, как замечательно ее отладили и убрали все известные ошибки. Ну и что – отвечает директор по закупкам – жизнь не стоит на месте, появляются новые идеи, новые вызовы перед бизнесом, нужна мобильность, высокая скорость реагирования на рынок и потребности клиентов, по плану закупа больше работать не можем. ИТ-директор обещает подумать и посовещаться.

Проходит неделя, директор по закупу снова подходит к ИТ-директору – а воз и ныне там. Мы еще думаем, анализируем, смотрим варианты. Заодно намекает, что новую схему закупа надо согласовать с продавцами, производством, финансистами, директором, в конце концов. Зачем? – удивляется директор по закупу – мы же всем этим ребятам делаем хорошо? Какая им разница, как отдел снабжения ведет закупки? Им ведь только лучше станет, даже финансистам – не нужно будет делать больших платежей, вероятность кассового разрыва меньше. Ладно, говорит ИТ-директор, я дам знать, когда решение примем.

Директор по закупу решает подождать, проходит еще одна неделя – ответа нет. Тут он совершает непростительную политическую ошибку – на общей оперативке заявляет, что поставил ИТ-директору задачу, а тот ее уже две недели динамит. Вопрос, говорит, важный, всей компании будет лучше, а этот чудак противится.

ИТ-директор унижен и оскорблен, и затевает ответную войну. В гневе бежит к программистам, и просит посчитать, сколько времени и денег ушло на построение старой системы. Пару дней они считают, добавляют часть стоимости коробочного продукта, затраты на сопровождение и тех.поддержку, услуги внешних подрядчиков. Полученную цифру ИТ-директор смело умножает на число Пи, как и положено настоящему менеджеру. Параллельно подсчитывается бюджет на автоматизацию новой схемы, и тоже умножается на Пи.

И вот вся компания узнает о том, как гнида директор по закупкам решил кинуть компанию на N миллионов рублей, в угоду своим, даже непонятно каким, интересам. Вероятно, просто хочет сымитировать бурную деятельность, чтобы появилась у него галочка – «внедряет изменения в отделе». Самое поганое – если предыдущую систему заказывал тот же самый директор по закупкам, потому что он получается вдвойне засранец. Если закуп по планам заказывал его предшественник, то еще куда ни шло – можно обвинить его в непрофессионализме. Начинается война интересов, через «верх» — совещания с глазу на глаз, потом очная ставка, потом экспертиза третьей стороны и т.д. А недели идут, уже месяцы пошли.

Допустим, у нас правильный директор по закупкам, которого действительно заботит эффективность. Он совершает вторую непростительную ошибку – не дожидаясь автоматизации, начинает вести учет в экселе. Его ребята вносят целевые уровни в таблицы, остатки и объемы размещения у поставщиков берут из системы (это первичные данные), там же в экселе ведут сроки поставок. Допустим, в угоду политике, чтобы не встрять окончательно, продолжают формировать старые планы закупа в системе – чтобы не было претензий.

Но претензии появляются, и очень быстро. План закупа в системе есть, а его выполнения – нет. Они ведь заказывают не 100 штук, как в плане, а 5, 4, 13 и т.д. Они не ходят продавцам объяснять, что те никогда не продавали 100 втулок в месяц, и цифра эта взята с потолка – продавцы просто страхуются от дефицита, затаривая склад. Потому что склад, его динамика и неликвиды находятся вне зоны ответственности продавцов. В итоге цифра, которая называется «план/факт закупа», быстро становится «плохой». В идеале должно быть 100%, а в реальности получается то 30 %, то 150 %, потому что объем реального закупа теперь диктуется скоростью отгрузки, а не фантазиями.

Директора по закупкам теперь начинают напрягать не только за желание выбросить миллионы на ветер, но и за банальное неисполнение своих обязанностей. Кто конкретно это делает – зависит от орг.структуры компании, но такая служба всегда найдется.

Теперь под угрозой само существование директора по закупкам – этого, конкретного человека, и выбор его незавиден. Редчайшие экземпляры идут до конца, продавливая свои изменения, применяя все возможные варианты воздействия – на директора, на ИТ-директора и других лиц, принимающих решения. Но основная масса просто бросает, потому что не находит ответа на вопрос «а нафига оно мне?».

Почему так произошло? Можно во всем винить политику, бюрократию, корпоративные интересы и подковёрные игры, но в чем первопричина? Почему такое простое изменение, на внедрение которого в самом функциональном подразделении уходят часы или дни, в остальных, взаимосвязанных отделах не может даже начаться?

Основная причина – информационная система и ИТ-отдел, главная задача которого вытекает из старой программистской мудрости – «не трогай то, что работает».

Можно поменять в этой истории некоторые составляющие, но результат почти всегда будет идентичным. Например, допустим, ИТ-директор у нас – полный лошара. Сейчас такое встречается нечасто, но раньше было нормой, т.к. ИТ-директором был главный программист или главный сис.админ, не искушенный в политике. Что будет в такой ситуации?

ИТ-директор сделает «под козырек» и, вроде как, побежит исполнять. А будет ли он исполнять? Нет! Он точно так же будет сопротивляться, только не открыто, а втихаря – методы всем известны. Например, будет задавать много вопросов – и директору по закупкам, и смежным руководителям. Запустит длинную цепочку согласований, с той же бухгалтерией, продавцами, финансистами – вот, мол, тут закупщики мутят изменения, на вашей работе они скажутся так-то и так-то, прошу обсудить и согласовать.

Смежные руководители, в отличие от директора по закупкам, на изменения не настроены. Если кто-то что-то там у себя меняет, например – унитаз в цехе, это их не сильно заботит. Но изменения у себя никто проводить не планировал, тем более с целью улучшения показателей смежного отдела. Начинается ропот руководителей.

Допустим, директор по закупкам обладает значительным политическим весом, и смог продавить изменения в смежных службах. Тогда каскадом, как фейерверк, вспыхивают проекты изменений в нескольких отделах. Причем, каждый из них содержит в себе автоматизацию.

Теперь уже несчастный лошара ИТ-директор завален проектами, которые надо оценить и выстроить в определенной последовательности. Почти всегда на первое место будет поставлен не проект директора по закупкам, а смежные, так сказать подготовительные. Например, изменения в системе бюджетирования. Раньше финансистам было удобно – из плана закупок автоматически генерировался кусок бюджета, т.е. план расхода денег был известен заранее, пусть и не был оптимальным с точки зрения денежного потока. А сейчас, вместо управляемой реальности, будут импульсные, непредсказуемые оплаты. Чем не повод затеять глобальный проект по изменению всей бюджетной политики компании? Да с автоматизацией?

Директор по закупкам опять остался не у дел, причем ситуация еще более патовая, чем в первом варианте. Война с открытым забралом была даже лучше – был ясен противник, его диспозиция и шаги. Сейчас же, вместо нормальной войны, возникло болото – традиционная ситуация с изменениями в российском бизнесе. Вроде никто против не высказывается, но что-то изменить – невозможно. И непонятно, что и с кем нужно сделать. Типичная реакция директора в такой ситуации – «проще всех разогнать и новых нанять». Слышали, или говорили такую фразу? Я слышал, много раз.

Вернемся еще раз к исходной ситуации, и представим идиллию – никто не сопротивляется, все двумя руками «за», все поддерживают изменения и болеют за предприятие. Бывает же такое? Наверное.

ИТ-директор искренне хочет побыстрее автоматизировать новую схему закупа, напрягает все силы для изменения или поиска готового решения. Только на один вопрос директора по закупкам ответить не может – а почему в нашей крутой системе, от известного вендора, такая схема закупа не присутствует в базовой поставке? Вроде она достаточно распространенная, и уже много лет. Здорово было бы, если бы мы просто переключатель где-нибудь в настройках щелкнули, и начали жить новой жизнью!

Но увы, переключателя нет, наша информационная система – снапшот, снимок требований компании на момент автоматизации. И директору по закупкам нечем крыть – он сам говорил внедренцам «у нас принято так – смотрим на план продаж, формируем план закупа, потом его исполняем». Ну да ладно, чего теперь сокрушаться и искать виноватых в старом проекте автоматизации – надо двигаться дальше.

Двигаемся дальше, ждем месяц-два, и вот система готова. Ура! Всего два месяца! Еще пару месяцев тратим на изменения в тех частях системы, которые отвечают за взаимодействие со смежными службами – те же бюджеты, статический план продаж выкидываем (он вроде не нужен больше), вместо него будет динамический портфель заказов, и т.д. Хватит пару месяцев? Пожалуй, нет… Ладно, пусть будет 4 месяца. Итого полгода. Все, счастье наступило. Вся компания напрягалась, работала, внедряла изменения, и наконец – все нюансы учтены, все критерии успешности достигнуты, все заказчики довольны, система работает. Запасы снижаются, продажи растут, денежный поток выравнивается, сроки отгрузки клиентам снижаются. Прелесть!

Но жизнь не стоит на месте. Директор по закупкам быстро понимает, что запасы, пусть и сниженные, слишком велики. Да и транспортные расходы тоже. Он узнает, из лучших практик, что теперь в тренде модифицированная версия методики – не возить от поставщика детали себе на склад, а договориться с ним о формировании запаса «под нас» на его собственном складе.

Схема просто прекрасна. Теперь 40 деталей лежат не на нашем складе, а на складе поставщика. А мы просто забираем на свой склад в любой момент столько, сколько нам нужно. Или даже не забираем себе – зачем лишнее звено? — просто грузим в машину и сразу отправляем покупателю. Наш склад вообще не участвует, даже в качестве транзитного.

Ну разве не прелесть? Особенно, если платить мы будем только за те детали, которые физически забрали, а не за весь объем произведенного поставщиком. Транспортные расходы снижаются, внутренние услуги по погрузке/разгрузке больше не требуются в прежнем объеме – можно сократить кладовщиков и грузчиков. Запасы снижаются еще сильнее, вплоть до освобождения прежде занятых складских помещений – теперь их можно использовать иначе, от сдачи в аренду до использования под производственные мощности.

Своим ребятам директор по закупу уже все объяснил, потратив на это пару часов. С несколькими поставщиками уже договорился. Мало того, некоторые поставщики признались, что де-факто уже давно так делают – им банально удобнее держать определенный запас деталей под нас, чтобы не дергаться на наш рваный закуп.

И вот герой с горящими глазами бежит к ИТ-директору. У того глаза уже несколько попритухли, после полугодового напряга с изготовлением нового снапшота – «информационной системы, удовлетворяющей всем требованиям заказчика». Слушает, кивает, пытается делать заинтересованное лицо. А про себя думает: ёёёёёё, это ж как мы будем учитывать запасы поставщиков? Это ж какую-то интеграцию с их системами надо делать? Мааааааать моя… А там у них наверняка такой зоопарк систем, которые и интегрироваться-то не умеют. С каждым отдельный обмен данными писать, наша система ведь не имеет никакой шины интеграции. Потому что ни в одной из версий снапшота о такой возможности речи не было. Остальные руководители на идею реагируют так же вяло. Юристы беспокоятся о перезаключении договоров. Бухгалтерия – о внедрении системы ответственного хранения (черт, там же еще и забалансовые счета придется использовать, раньше избавлял от них Господь как-то). Транспортники переживают об усложнении маршрутов – не поедешь же за пятью деталями в другой город? Надо ехать сразу к нескольким поставщикам, чтобы был сборный груз. Отдел качества недоумевает, как ему теперь детали проверять – раньше-то ему во двор все привозили. А теперь как? Выездные проверки делать? Системы контроля качества согласовывать? Блин, не знали горя…

Общий энтузиазм равен нулю, или почти нулю. Совместное мнение – ты, конечно, классный чувак, здорово заботишься об изменениях и судьбе компании… Но ведь из-за тебя полгода напрягались, а ты, не дав отдохнуть, затеваешь новые изменения. Давай хоть годик отдохнем, привыкнем, мы еще свои процессы не устаканили, периодически сбои возникают. Горшочек, не вари.

По какому сценарию двинется изменение?