Инертность организаций

Если инертность - неотъемлемое свойство организаций, то надо научиться управлять организацией с учетом этого свойства. При неумелом управлении инертность может свести к нулю все усилия по изменениям. Когда речь идет о дорогостоящих проектах, это нельзя н

Многие консультанты утверждают, что существует методология внедрения систем управления (или других серьезных инноваций) в короткие сроки. Для жизни компании два-три месяца — это короткий срок.

Однако существуют причины, по которым длительный срок внедрения неизбежен.

Любая компания, затеяв серьезный проект, в случае неудачи не станет публично признавать свою беспомощность и объявлять, что проект не завершен в срок или завершен в гораздо меньшем объеме, чем планировалось. Это естественно — компания должна представлять себя в лучшем свете, «не вынося сор из избы», чтобы не терять клиентов и партнеров.

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

Как правило, внедрение информационной системы масштаба предприятия, особенно на базе методики MRP II, предполагает коренное изменение мышления и подхода к управлению. К сожалению, этого не понимают на многих предприятиях, завершивших подобные проекты. Видимо, это одна из причин неуспешного внедрения.

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

До определенного момента предприятие, по аналогии с законами физики, «двигалось равномерно и прямолинейно», но возникла необходимость изменить направление или скорость его движения, а для этого надо применить силу. В данном случае сила может быть выражена достаточно точно через количество ресурсов, направляемых непосредственно на решение этой задачи. Существует много способов измерить «траекторию» предприятия и ее изменения. Рассмотрим силы, которые необходимо приложить для успешного внедрения на предприятии информационной системы, и способы их оценки. Очень важно также правильно определить «точку приложения» сил, чтобы, например, не столкнуть с рельс организацию. Необходимо оценивать указанные силы по трем параметрам: величина — в рублях, точки приложения — изменяемые ресурсы, направление — планируемое состояние, которое, как правило, определяется целями. Будем называть инерцией бизнеса его склонность сопротивляться изменениям, выводящим его из состояния равномерного движения (развития).

Рост — это неотъемлемое требование к участникам свободного рынка. Если предприятие хочет сохранить свою долю рынка, то эта доля в абсолютном выражении должна расти, поскольку сам рынок растет. Если обороты (выручка) предприятия растут, то это еще не повод радоваться. Если скорость роста ниже, чем скорость роста того рынка, на котором работает предприятие, то это говорит о грядущих проблемах. При скорости роста бизнеса, равной скорости роста рынка, для предприятия наступает состояние стагнации. Если хотя бы один конкурент захочет увеличить долю рынка, вы свою долю можете потерять. Конечно, к естественным монополиям это не относится.

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

Можно ли измерить, и что?

При оптимальном применении силы инертность можно преодолеть самым лучшим образом, при неправильном — можно еще больше ее увеличить, потеряв при этом средства и время, а самое главное, породив у сотрудников сомнения в безупречности руководства и принимаемых решений.

К параметрам движения предприятия относятся параметры, связанные с персоналом (доля довольных сотрудников), параметры, характеризующие бизнес-процессы (доля документированных процессов), параметры, характеризующие отношения с клиентами и финансовое состояние предприятия.

Необходимо также определить возможные точки приложения силы, то есть виды ресурсов предприятия, на которые необходимо воздействовать. На мой взгляд, это персонал (управленцы, специалисты и рабочие), система управления, средства производства, партнеры.

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

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

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

Что такое «понял на самом деле»

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

Встречаются заявления, что проект завершен через три месяца! Разумеется, многое зависит от объема, например, установить кассовые аппараты и запустить их в работу можно и за этот срок. Но, по моему опыту, в эти сроки завершается только официальная, или формальная часть проекта. Эффективное использование результатов в таких случаях значительно запаздывает. Я считаю это нормальным, и лучше об этом сразу говорить и готовиться к этому. Случается, что когда «быстро» проведенное внедрение доходит до пользователя, то это решение уже надо менять или выходит новая версия продукта, с новыми функциями или неузнаваемо измененными старыми. Рекомендую объявить мораторий на обновление версий программных продуктов в ходе проекта и даже на пару лет после его завершения.

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

Другое важное изменение — это появление достаточно большого количества совершенно новых функций и ограничений, накладываемых программным продуктом (очень важной частью интегрированной системы управления). К таким ограничениям надо отнести жесткую классификацию и кодирование многих справочников и создаваемых документов, без чего работа в системе только усиливает хаос. Во всех проектах, в которых я участвовал, этот вопрос решался на протяжении всей работы — и на стадии разработки, и уже во время реальной работы в системе. Конечно, основная работа по классификации и кодированию относится к номенклатурному справочнику. Но при кодировании номенклатуры есть очень большая зависимость от программного комплекса и возможности использования заложенных в нем функций (например, наличия простого и значительно уменьшающего потребности в вычислительных мощностях способа поиска и сортировки как позиций номенклатуры, так и документов с ее использованием). Понять это пользователям без практики непросто, надо, чтобы они получили такую практику, а на это необходимо время. Существуют традиционные способы: разработка и проведение в системе контрольного примера, тестового примера (при этом необходимо обращать внимание на структуру справочников, которая должна быть не только логична и удобна, но и позволять в дальнейшем проводить анализ данных в нужных разрезах). Кроме номенклатурных, необходимо серьезно подойти к кодированию и классификации других справочников и документов. В ходе проекта пользователь должен работать и учиться в системе. Это надо для того, чтобы проектировать изменения в своей работе. В решении этого вопроса участвуют две стороны: консультанты, знающие систему и имеющие опыт (не всегда исчерпывающий), и пользователи, знающие предметную область (часто не полно). Соединить знания этих двух групп оказывается не всегда просто. На это уходит время. Очень важным фактором успеха является практика работы в системе и тесное сотрудничество — в том числе неформальное — участников, представителей консультанта и заказчика.

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

В случаях, когда консультанты предлагают обследование, затем «разрабатывают» или предлагают отраслевое решение практически по молчаливому согласию пользователей, получается хорошо прогнозируемый результат. Консультанты уже запустили систему (или сдали пакет регламентирующей документации), наступила очередь пользователей, а они не совсем поняли, почему так «решили». Если разобрались хорошо, то начинают удивляться лишним и бесполезным операциям и неверному применению некоторых функций системы. К тому же многие «большие» системы, по сути своей, созданы для планирования, но очень редко для этого применяются и являются в первую очередь учетными системами, следовательно, используются не по назначению. Эти примеры, конечно, прежде всего характеризуют компанию консультанта и ее сотрудников, но и компанию-заказчика — тоже. Ее сотрудники полагают, что кто-то за них подумает и, более того, примет решение.

Случаи из практики

При знакомстве с сотрудниками одного клиента на семинаре по MRP II директора и специалисты приговаривали: нам именно это надо, мы так и сделаем. Начали работать, не торопясь, но по-серьезному. Через полгода приняли решение провести подробный семинар с аттестацией ключевых перспективных сотрудников. После того как слушатели были аттестованы, директор мне сказал, что он, наконец, понял, о чем я говорю, что это все очень непросто и в самом деле очень нужно их предприятию, и с еще большей энергией стал стимулировать персонал к освоению методологии и применению ее в оперативной работе. При этом проект автоматизации уже шел.

В другом проекте система работала, персонал работал в системе (кстати, было объявлено о завершении внедрения), но результаты работы не были востребованы по одной причине — руководство не использовало данные системы для принятия решений, а очередной руководитель заявил на совещании, что осведомлен о величине остатков и потребностях лучше системы. Это случилось через несколько лет после начала масштабного обучения, разработки проектных решений, сертификации по ISO и пр. Директор по производству, участник проектной команды, спустя четыре года с момента запуска системы, сказал: «Система нам мешает, она отвлекает нас от основной работы». При этом дефицит никуда не делся, нормативы как отсутствовали, так и не появились, себестоимость как была загадкой, так и осталась таковой.

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

В одной компании я полгода рассказывал про планирование на основании статистики. Мне говорили, что особенной статистики нет, но ее надо копить и все понимают зачем. Спустя месяц один из руководителей пожаловался, что они третий год подряд пропустили рост спроса в сентябре, и у них третий год подряд склады оказались пустые, что привело опять к неудовлетворенности клиентов. Этот пример демонстрирует неспособность людей делать комплексные выводы. Все способны запомнить события и их последовательность, но понять, как поступить, чтобы предотвратить хотя бы часть проблем — это трудная задача, и она называется планированием.

В другой компании мне рассказывали, как хорошо они уже много лет управляют несколькими географически распределенными складами (розничными точками продаж) в единой системе на основе MS Navision и «1С». Всюду были определены точки заказа по каждой позиции, и центральная система получала сведения о реальных запасах. Затем регулярно осуществлялись поставки по позициям, достигшим точек заказа, с центрального склада. Я попросил показать мне систему в центральном офисе. Когда мы смотрели систему с директором, вопросов было много, но один был самый интересный. Я заметил достаточно много заказов покупателей, которые имели странный статус. Я попросил рассказать о значении этого статуса. Мне ответили, что это неудовлетворенные заказы. Оказалось, что в магазины клиенты обращались с просьбами поставить запасные части (речь идет о компании, продающей сельскохозяйственную технику и запасные части к ней). Пользователи в точках продаж честно вносили в систему заказы, но, поскольку таких позиций не было в центральной системе и точек заказа для них тоже не было, заказы оставались неудовлетворенными.

Еще одна оптовая компания с очень большим товарооборотом приобрела OLAP-систему и с ее помощью три сотрудника регулярно занимались «планированием». Основной их целью было планирование спроса, для того чтобы спланировать закупки. Я был очень удивлен, когда узнал, что статистические ряды, которые были основой для прогнозирования спроса, были отгрузками! Отгрузки являются реакцией компании, с учетом ее возможностей, на спрос. Эта реакция часто вносит дополнительную неопределенность. Поэтому для прогнозирования спроса надо учитывать спрос. Что касается отгрузок, необходимо, чтобы мощности по отгрузкам соответствовали прогнозируемому спросу.

Эти примеры я привожу, чтобы подчеркнуть: ошибки в работе часто носят системный характер и порой глубина этих ошибок слишком велика, чтобы быстро их исправить. Работа по их устранению тяжела и кропотлива Сомневаюсь, что есть консультанты и специалисты, способные за короткий срок правильно диагностировать подобные ошибки и дать рекомендации по их устранению. Ведь ошибки живут в головах людей. Что касается создания систем управления, в основе которых лежат объемные данные о номенклатуре, спецификациях, технологических маршрутах, производственной и складской структуре и пр., и структура этих данных определяет характеристики системы планирования, то в начале пути, при определении структуры данных, надо хорошо понимать, какова будет система планирования. Конечно, в начале пути у любого участника проекта (даже опытного консультанта) о будущем решении на конкретном предприятии, с конкретной культурой и законами существуют только общие представления.

Аркадий Агапов — независимый консультант, arkadyaa@rambler.ru