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

Введение

В 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.

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

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

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

Выводы

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

Подробнее
Реклама
Комментарии 10
  • 0
    К сожалению, данные примеры не единственные, но на мой взгляд гораздо хуже, когда внедрение новой методологии, сводится к внедрению некого ПО без понимания зачем и почему внедряется методология.
    • +2
      В ИТ для многих компаний главное — это продать. А на сколько оно будет удовлетворять потребностям клиента уже не сильно задумываются. Также, часто бывает, что в больших системах персонал не понимает как пользоваться всеми благами и продолжает работать по старинке, т.к. боятся изучать что-то новое.
      Подскажите, пожалуйста, начинающим аналитикам, каким инструментарием пользуетесь, где и как набирать опыт, какие книги стоило бы прочитать.
      • 0
        Сильно сомневаюсь что сферовакуумный аналитик смог бы решить положительно любую из описанных ситуаций. Нужен скорее не аналитик, а консультант, который понимает не только бизнес, но и средства автоматизации. А в идеале такой консультант должен еще до запуска проекта объяснить заказчику все подводные камни внедрения систем.

        Бумажки типа ТЗ\ХЗ совершенно не важны для внедрения, довольно странно что отсутствие формального ТЗ выставляется как недостаток, а наличие — как преимущество.
        • 0
          Я подозреваю, что под ТЗ автор разумеет совокупность бизнес-, функциональых и пользовательских требований к проекту, которые согласованы между заказчиком и подрядчиком. А ТЗ — это, вообще-то, внутренний документ подрядчика, с точки зрения контроля качества желателен, но, в принципе, на усмотрение подрядчика (хотя отсутствие ТЗ в крупном проекте характеризует подрядчика не лучшим образом).

          >Бумажки типа ТЗ\ХЗ совершенно не важны для внедрения

          В статье поясняется — нет ТЗ (т.е. зафиксированных требований, как я понимаю автора), нет гарантии. Нет гарантии — нет ответственности.
          Но в общем, даже требования вторичны. Главное — «соблюдение базовых принципов этики», о чём автор тоже говорит.
          • 0
            «Нет ТЗ — нет гарантии» вовсе не означает «Есть ТЗ — есть гарантия». Согласовать ВСЕ требования заранее даже на маленьком проекте сложно, а на большом так и вовсе невозможно. Так что все это не более чем громкие слова.

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

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

              Согласовать ВСЕ требования заранее даже на маленьком проекте сложно

              Это не означает, что нужно вообще отказаться от согласования требований и их фиксации.
              • 0
                А я не говорю что надо отказаться, да и никто не говорит, как я понял. Но зачем об этом писать?
                Если на проект нагнать аналитиков успешнее не станет, увы. Я даже много обратных примеров видел.
        • 0
          Заказчики, они как дети — им нельзя говорить «ты — дурак» или «у тебя всё плохо». Сначало надо показать вкусные ништяки, а уже потом способ их достижения.
          По теме статьи — нужна грамотная аналитика. С акторами, юзкейсами, сценариями. А уж потом — архитектура и ТЗ.
          • 0
            Вообще никому не стоит говорить «ты — дурак», особенно если ты с этим человеком бизнес хочешь делать. «Вкусные ништяки» не нужны если они не решают проблемы. Поэтому показывать как раз надо проблемы, но не в стиле «у тебя все плохо», а «смотри, у XYZ все было как у тебя, а потом стало лучше потому что они начали использовать ABC».
          • 0
            Наличие проектной документации — это всегда больше преимущество, чем недостаток. К сожалению, бывает документация, которую как раз можно больше отнести именно к «недостаткам», а в договорной базе отсутствуют даже минимальные требования к оформлению, содержанию и используемым нотациям. Гарантийные обязательства — вопрос комплексный, который должен быть предусмотрен и на уровне договора, и на уровне документации, так как иначе будет непонятно, на что именно эти самые обязательства распространяются.

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

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

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.