Автоматизация и-или результат?

в 19:32, , рубрики: автоматизация, внедрение по, результативность, управление проектами, Читальный зал
Введение

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

По своему ощущению, могу совершенно однозначно заявить, что грамотность большинства бизнесменов в вопросах автоматизации хоть и сдвинулась с места, но еще далека от той точки, когда люди будут хорошо понимать, за что же именно они платят. Более того: те, кто продают автоматизированные системы управления, редко и сами представляют, за что же они получают деньги. Низкая результативность внедрений вида невооруженным глазом: системы BI, которые призваны дать инструментарий конечному пользователю, но на деле требуют содержания штата мощнейших программистов и аналитиков, дорогостоящие ERP, где за красивым «фасадом» вместо обещанных ноу-хау обнаруживается банальная арифметика, и системы контроля исполнения, которые дают некорректные задания исполнителям. Стоимость же ошибки в наше время поражает воображение: неправильно выполняемые задачи способны «съесть» не то, что миллионы, а миллиарды рублей!

Специфика моей работы такова, что приходится проводить множество экспресс-аудитов именно по результатам внедрения информационных систем. Только за последние 2 недели мне удалось побывать на 4-х предприятиях, которые продемонстрировали: неэффективную систему BI, некорректно работающую WMS, просто неработающую MES, а до кучи — полное непонимание результата. Самым удивительным было то, что заказчик при этом легко соглашался «написать ТЗ» для исполнителя, ничего не понимая в предметной области, а исполнитель совершенно без проблем принимал в работу плохо структурированный текст, к которому больше применим термин «поток сознания», чем «документ». Что еще более удивительно, заказчики подчеркивали следующие «положительные» характеристики компаний-внедренцев:
1) «Сэкономили кучу времени, отказавшись от формализации процессов»
2) «Согласились выполнять все доработки прямо в режиме опытной эксплуатации, не фиксируя их в документах, чтобы не увеличивать бюджет проекта»
3) «Настоящие профессионалы! Даже без обследования рассказали, какие будут настройки в системе!»
Теперь предлагаю рассмотреть по очереди те случаи, с которыми мне совсем недавно пришлось столкнуться.

Случай 1: Неэффективная BI

Компания приобрела очень дорогостоящий продукт, когда узнала, что пользователи смогут самостоятельно разрабатывать все необходимые им отчеты. Менеджер по продажам красочно изложил прекрасную концепцию, когда генеральный директор при помощи своих любимых инструментов строит сложнейшие отчеты, прогнозирует продажи, получает уведомления о наименее эффективных сотрудниках, и многое-многое другое. Между точкой отсчета и мечтой директора препятствий было всего-то два: заключить договор и заплатить за продукт и работы. Удивление пришло немного позже, когда к руководителю пришли консультанты, чтобы получить от него информацию о тех отчетах, которые он желает видеть. Когда он напомнил им про «любой отчет своими руками», его мягко подкорректировали: отчет-де своими руками сделать можно, но перед этим надо настроить модель данных, и если в этой модели не предусмотреть каких-то объектов, то и в отчетах их использовать будет невозможно.

Руководитель быстро принял решение: созвал всех топ-менеджеров и аналитический отдел, и свел их напрямую с консультантами, наказав придумать максимально возможное количество объектов для анализа. Хорошо подумав несколько дней, они презентовали свои наработки консультантам, на что получили еще одну мягкую поправку: невозможно построить запрос из объектов, никак не связанных друг с другом, так что теперь требуется проработать все возможные ракурсы для анализа данных.

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

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

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

Случай 2: Некорректно работающая WMS

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

Проблемы начинаются с топологии склада: буферные места никак не отражены в системе, а находятся под контролем у складских работников. При этом, отсутствует регламент, в котором бы фигурировали хотя бы общие сведения о том, как этот контроль осуществлять. Развернуты огромные ячейки на 12-15 поддонов, а этикетка, которая клеится на поддон, имеет очень маленький размер. Это значит, что при выполнении задания сотрудник вынужден искать поддон с конкретным номером, вчитываясь в каждую этикетку, и снижая свою производительность на коротких операциях в 3-4 раза. Дальше — больше: при размещении на полках, система не рекомендует, в какое конкретно место требуется разместить груз. Персонал делает это на свое усмотрение, а его усмотрение — это «пришел поддон — размещаем поддоном, пришла коробка — размещаем коробку». При этом, никто даже не задумывается о том, что некоторые товары приходят целыми палетами, а уходят медленно и печально, так что этой палеты хватит месяца на 3-4. Какой смысл для такого непопулярного товара занимать целое палетоместо, если можно осуществлять пополнение полок?

Всего перечислять не буду, так как в результате двухчасового забега по складу получился солидный отчет, а главное — конкретные рекомендации о повышении производительности. Что удивительно: подрядчик, внедрявший продукт, даже не писал техническое задание. Он руководствовался пожеланиями заказчика, а большая часть функционала была переработана уже в период эксплуатации системы. Заказчик рассмотрел в этом преимущество: сотрудники подрядчика были готовы выполнять доработки прямо по его словам! Однако, реальность оказалась гораздо более печальной: ни в одном документе указанные доработки не зафиксированы, и гарантия от поставщика распространяется только на «коробочный» функционал, описание которого заказчик получил по факту оплаты лицензии.

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

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

Случай 3: Неработающая MES

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

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

В общем, за реализацией обратились к местному системному интегратору, который согласовал ТЗ, реализовал заданные процессы, и «выкатил» заказчику свой продукт. А дальше — как в лучших комедиях: смотрит заказчик на продукт, и не понимает: вроде, все, что хотели — реализовано, а что имеем на выходе — непонятно. Так, не разобравшись, и приняли продукт, подписав даже пресс-релиз об успешном использовании. Дальше сели в кружок перед компьютером, и начали осваивать. Не поняли. Снова попытались — снова не поняли.

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

Выводы

Описанные случаи — это лишь вершина айсберга. Могу привести множество примеров, когда заказчик буквально руками и ногами упирался, отстаивая свою позицию, чтобы через несколько месяцев хмуро сказать: «Кажется, я понял». А кто-то даже не признается, отстаивая свою позицию и теряя конкурентоспособность только потому, что не хватает характера признать свою неправоту. Все же человеческий фактор — это мощнейшая сила, которую можно использовать как во благо, так и во вред. Но заказчик — он и в Африке заказчик. У него деньги, он их платит, и поэтому имеет право не знать, будучи готов оплатить это незнание. Больше удивляют поставщики, которые похожи на джиннов с подвохом: каждое желание должно быть детально продумано, зафиксировано, и подписано. Однако, если мы посмотрим на европейский опыт, то там такой подход применяется крайне редко: профессиональные поставщики решений развивают свои компетенции и готовы предложить множество «юс кейсов» по своей продукции, а также разработать индивидуальное решение с полномасштабным технико-экономическим обоснованием. Никто не освобождает бизнес от соблюдения базовых принципов этики, а уж если «назвался груздем», то «полезай в кузов», и набирайся знаний о той области, в которой работаешь. Знаете, какая профессия сейчас в большом дефиците? Именно аналитики. Программистов — навалом, руководителей — аналогично, а вот грамотных аналитиков — днем с огнем поискать. От этого результативность проектов и страдает: внедрять продукты буквально с закрытыми глазами, полагаясь лишь на удачу — слишком дорогое удовольствие, за которое — в результате — платят все: заказчик — деньгами, поставщик — репутацией.

Автор: LOGX

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js