Хабрахабр

Внедрение изменений в автоматизированном бизнесе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть