Эффективная цифровая трансформация ритейла и производства

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

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

Возможности цифровой трансформации. Как отличить возможность от мечты

Возможности и требования

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

Боюсь, минимальные оценки от максимальных легко могут отличаться на порядок! Кто-то скажет: "Можно за день все пропылесосить, отгрунтовать, занести раскладушки и жить" (затраты – один человеко-день). А другие будут настаивать: "Квартира – это надолго, поэтому необходимо подождать, пока освободится лучший дизайнер, и с ним вы за полгода проработаете подходящий под вас дизайн, затем лучшие специалисты за квартал-другой разработают технические проекты, за полгода компания выполнит черновую отделку и инженерные работы, за полгода сделает чистовую отделку…"

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

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

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

Стоимость цифровой трансформации. Можем оценить окупаемость и риски?

Сроки и стоимость

Привычный подход для определения стоимости и сроков проекта – рассчитать их, исходя из сформированных требований. Вроде бы логично: мы же затеваем проект потому, что получили некое представление о целях. Цели, очевидно, можно преобразовать в требования, откуда несложно понять, сколько нужно времени и денег на реализацию. но так ли это?

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

Вот только недостатком этой методологии считается невозможность просчитать сроки и стоимость.

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

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

Смогли продумать пять самодостаточных версий – хорошо, десять – еще лучше! Похоже, что для их реализации хватит запланированных времени и денег? Отлично, у вас есть вероятные бюджет и срок реализации проекта!

Риски цифровой трансформации. Для снижения рисков снижать требования

Риски

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

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

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

Грань между необходимостью и избыточностью

Такую грань достаточно легко провести, если подходить к реализации проекта, как говорится, итеративно и инкрементально.

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

Грань между необходимостью и избыточностью

Примеры влияния требований на стоимость и риски проектов

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

Проект по кросс-докингу

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

Один из проектов снижения издержек – переход на кросс-докинг. Более года идут попытки реализовать задуманное, но без особого успеха. Виной тому неготовность радикально жертвовать требованиями, продвигаясь к цели шаг за шагом. В рамках проекта компания хочет большую часть бизнеса перенести в Odoo ERP (система с открытым исходным кодом на Python + PostgreSQL), оставив хорошо известной в России системе лишь функционал налоговой отчетности и кадрового делопроизводства.

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

• перейти от полуручной к автоматической маршрутизации транспорта и увязать это с кросс-докингом;
• автоматизировать документооборот водителей.

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

Что дает наибольшие и наименьшие выгоды? На складе есть надежда сократить площади в 2–3 раза и разгрузить персонал примерно вдвое. При этом маршрутизация транспорта работает, хотя и в полуручном режиме, но нагрузка всего на одного человека в день – можно отложить. Автоматизация документооборота сулит снижение издержек примерно лишь на одного человека – тоже можно отложить. дальше сократить требования сложнее, но можно. Как?

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

В итоге при наличии склада кросс-докинг можно разделить на два процесса:

1. разгрузка фуры на склад сразу с зонированием не по товарам, а по маршрутам будущих отгрузок (с зонированием по клиентам);
2. заполнение курьерского транспорта со склада.

Первый процесс можно реализовать независимо от второго, что минимум вдвое снижает требования. Да, процесс загрузки фур в новом варианте может занимать больше времени, чем прежде, так как придется сортировать приход по клиентам, а не по товарам, но взамен существенно сокращается сложность проекта. Можно ли еще сократить требования? И опять ответ: можно!

Кроме собственных товаров с малым сроком годности (напомню, с еще не сформированными требованиями к номенклатуре в ERP, необходимой проекту автоматизации производства), есть сторонние товары с длительным хранением. А среди этих товаров есть один поставщик с двумя видами товаров, ассортимент которого включает в себя лишь несколько десятков позиций. Более того, если при реализации проекта что-то пойдет не так, то задержка поставки товара даже на несколько дней не окажет на компанию никакого влияния. Таким образом, требования к справочнику товаров для первой версии сократились на пару порядков! Что нужно, чтобы такой функционал можно было использовать? Потребуется (это соответствует упомянутому выше методу проектирования по контракту):

• передавать информацию о приходе из прежней ERP в новую (чтобы разместить товар на складе, можно либо передавать информацию из прежней системы, либо формировать в новой – это не существенно на данном этапе);
• доработать интерфейс для терминалов сбора данных (ТСД) в новой ERP;
• передавать в старую систему фактически принятый товар и его фактическое размещение.

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

Итого переработанный проект получил следующие "вехи":

• приемка через новую ERP приходов от одного-единственного поставщика с относительно редкими допоставками;
• оптимизация интерфейса и приемок всех сторонних поставщиков через новую ERP;
• заполнение в новой ERP свойств номенклатуры собственного производства и приемка своих товаров через новую ERP;
• отгрузка пары маршрутов с наименее требовательными клиентами через новую ERP;
• оптимизация интерфейса и автоматизация процесса маршрутизации на базе новой ERP;
• автоматизация процесса доставки товаров до клиентов;
• отгрузка всех клиентов через новую ERP и минимизация использования прежней системы (передача в нее только информации для фискальной отчетности).

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

Усечение требований

Проект автоматизации производства

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

Это и дополнительные расходы, и человеческий фактор, так как каждый мастер параметры обточки выполнял по-своему. Оба фактора компания сочла критичными для реализации своих бизнес-амбиций. Годовые расходы на ручной труд дали примерное понимание приемлемого бюджета на автоматизацию. Оставим в стороне варианты, которые были рассмотрены и отложены в "копилку" ввиду разных причин. По итогу компания решила попытаться реализовать задачу своими силами, а если возникнут сложности, то вернуться к другим вариантам (оставить ручной труд – один из таких вариантов).

Какие сложности были выявлены на пути к цели? Настройка станка требует формирования нескольких десятков параметров, индивидуальных для каждого заказа, в ERP информации для этого нет почти никакой:

• каталог линз – около 40 позиций, за каждой скрывается от 5 до 200 тыс. SKU (Stock Keeping Unit, единица складского учета), итого около 5 млн SKU, из которых в ERP внесено порядка 30 тыс.;
• для каждого SKU необходимо заполнить около десятка свойств;
• часть свойств линз транслируется в настройки станка напрямую, а другая часть является лишь частью алгоритмов создания настроек, которые только предстоит формализовать;
• на витринах и на складе тысячи оправ, все их нужно отсканировать, а также добавить немного свойств в справочник номенклатуры;
• часть настроек зависит от индивидуальных параметров заказа, и для их оцифровки требуется доработать интерфейсы розницы;
• технология создания файла настроек станка не документирована производителем по финансовым соображениям – чтобы соглашались использовать их решение для интеграции, которое обладает своими недостатками, помимо цены, удваивающей срок окупаемости первого станка.

Если этот проект запускать монолитно, ожидая успешного внедрения методом "большого взрыва", разумным выбором стал бы вариант "оставить все как есть" – настолько велика неопределенность по каждому пункту выше. Однако можно капитально сократить требования.

Предположим, что реализовать своими силами интеграцию станка с ERP не получится и позже придется привлечь к интеграции поставщика станков. Чем можно помочь инженерам уже сейчас? Файл настроек состоит из описания формы оправы, описания параметров линз, перечисления параметров заказа, принятого в магазине, и десятка настроек, формируемых исходя из всего этого. Один из параметров заказа, который к тому же наиболее критичен, уже заполняется розницей, но кое-как. Подавляющая часть заказов изготавливается из складских оправ, из них популярные составляют менее 10% – можно отсканировать пока только эти, а заказы с прочими изготавливать как раньше. В итоге, если в качестве первой версии автоматизации создавать файл, в котором уже будет скан нужной оправы и один-единственный доступный параметр, – это уже подспорье, а также проверка реализуемости проекта.

На реализацию ушло меньше месяца, неопределенностей в этой части проекта было крайне мало, риски пустой траты времени и денег несущественны. Весь проект отказа от ручного труда занял менее полугода. Этапы были следующими:

• автоматическое формирование файла настроек, содержащего форму оправы и один-единственный параметр (первые несколько вариантов были собраны вручную, после чего их формирование и передача были автоматизированы – был создан минимально жизнеспособный продукт, MVP);
• выполнение на станке только одной из 40 позиций линз (менее 5 тыс. SKU) и только самых простых для настройки станка оправ (такая комбинация позволила отправлять на станок порядка 30% заказов);
• постепенная формализация каталога линз, доработка интерфейса розницы с одновременным заполнением файлов для станка, журнала для инженеров с выполняемыми ими настройками для формализации алгоритмов;
• версия, формирующая все настройки для станка, журнал для инженеров для регистрации вносимых изменений, ответственность за брак на инженере;
• запрет инженерам вносить правки в настройки для каждого заказа, исправление настроек только в случае брака, с регистрацией сделанных исправлений в журнале, ответственность за брак на компании;
• отказ от ручного труда, журнал исправлений настроек заполняет дежурный инженер;
• расширение ассортимента оправ и линз, выполнение на станке 99% заказов (эта часть не входит в указанный полугодовой интервал).

Сейчас в России около девяти таких станков в пяти сетях оптик, из них четыре станка в "Айкрафт". Только в "Айкрафт" труд инженеров автоматизирован. Без поэтапного подхода к проекту и в "Айкрафт" до сих пор настройки делали бы вручную, так как решение поставщика для интеграции с ERP зарубежные коллеги предпочитают покупать при наличии примерно шести станков, то есть компании потребовалось бы вырасти еще раза в полтора.

Проект снижения трудозатрат на складе

В какой-то момент в компании назрела потребность увеличить штат комплектации либо оптимизировать работу сотрудников.

Каков бюджет? Предположили, что добавление в смену одного сотрудника позволит на год закрыть проблему. Итого бюджет – расходы на двух сотрудников за 1–2 года. Сроки, понятное дело, – "вчера". Учитывая предстоящие летние отпуска, недостающих работников решили набрать, а когда эффективность склада будет повышена, сократить за счет текучки.

Каковы требования? Глупо изобретать велосипед, поэтому начали с изучения рынка: выставки, поставщики WMS, визиты на автоматизированные склады. На выходе получили несколько устраивающих нас технических предложений от интеграторов, вот только окупаемость наиболее простого варианта мы оценили в четыре года и срок реализации – ближе к году. Чтобы не отказываться от автоматизации вовсе, решили отказаться от части требований и реализовать на базе имеющейся ERP следующее:

• не формировать в системе отдельные документы под каждую операцию комплектации заказов на производство (немного сложнее "искать концы", но реализация намного проще);
• использовать адресное хранение только для зоны комплектации (ручные операции на других участках несущественно нагружают персонал);
• не автоматизировать запуск инвентаризации при отсутствии товара в ячейке (если товар для заказа не найден, заказ откладывается в отдельную кучу, если не найден при пополнении магазина, товар пропускают – отправят в другой раз);
• не хранить несколько товаров в одной ячейке (часть рядов промаркировали чаще, по размеру минимальной ячейки);
• один товар размещать только в одной ячейке (часть товаров физически занимают несколько ячеек, привязка идет по первой);
• ряд других менее существенных требований также были вырезаны.

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

• грубо зонировать оправы согласно ABC-анализу, добавить в бланк комплектации заказов для производства зону хранения оправы, оставить комплектацию по бумажке – таков был минимально жизнеспособный продукт;
• реализовать адресное хранение с точностью "модель – ячейка", вручную заполнить в ERP адреса хранения оправ, выдавать заказы на комплектацию по порядку хранения на складе;
• запросить доработку интерфейса ERP для комплектации заказов на пополнение запасов магазинов при помощи ТСД, создать интерфейс привязки через ТСД товаров к ячейкам, привязать все товары к ячейкам;
• пока готовится программа для ERP, выдавать на печать форму комплектации запасов магазинов с сортировкой по местам хранения;
• безбумажная комплектация пополнения магазинов при помощи ТСД;
• запросить доработку интерфейса ERP для комплектации заказов для производства при помощи ТСД;
• переход на безбумажную комплектацию заказов для производства.

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

Проект реорганизации интерфейса в рознице

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

По правде говоря, я немного лукавлю. К моменту, когда мы задались такой целью, мы уже точно знали, что это возможно. Процесс оформления очков действительно достаточно сложный, и в 2011 г. на оформление одного заказа требовалось от 5 до 15 мин., но к 2013 г. была проделана большая работа без замены имевшейся системы – трудоемкость удалось сократить до 2–3 мин. на заказ. Дальнейшая оптимизация требовала более значительных инвестиций, и хотелось одновременно решить сразу несколько проблем.

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

Каковы риски? Риски велики, если пробовать реализовать все разом. Но опасения были купированы Agile-подходом. в Odoo ERP ожили следующие подпроекты:

• реализован лаконичный интерфейс пополнения базы зрения клиентов (работа розницы упростилась, программисты освоили новую систему);
• добавлен интерфейс анкетирования клиентов (повысились возможности маркетинга);
• старые DOS-подобные кассы с аппаратной клавиатурой переведены на графический тачскрин-интерфейс (экономия на прежних лицензиях, ниже требования к оборудованию, часть продаж уже можно выполнять с планшета или смартфона, без ПК);
• создан веб-интерфейс для оформления заказов (в каждом магазине появилось по планшету на сотрудника, буклет по освоению нового интерфейса занимает один лист с двух сторон, почти никто его не читает – и так все понятно; инструкция встроена в систему, с ней знакомят новобранцев, дальше к ней никто уже не возвращается);
• создан интерфейс для оформления редких операций (в том числе ремонта), повышены удобство, скорость, надежность системы, реализована возможность безбумажной работы с клиентом;
• кассовая отчетность переведена в электронную форму.

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

По шагам – к цели

Не столь важно, по какой методике реализовывать инновационные проекты: по каскадной модели (водопад – англ. waterfall), по методике PMBoK, по Scrum или согласно принципам Agile. В любом из вариантов самое важное, что позволяет минимизировать риски, – снижение требований. Об этом в ИТ-мире писали и в середине 1960-х гг. ("Мифический человеко-месяц"), и в середине 1990-х гг. ("Путь камикадзе"), и в начале XXI века ("Scrum. Революционный метод управления проектами", "Скрам: гибкое управление продуктом и бизнесом"). Не нужно пытаться сделать все с первой попытки, стараться объять необъятное. Практичнее продвигаться по чуть-чуть, корректируя пожелания после каждой итерации. Дорогу осилит идущий, главное – верить в себя и свою команду!

Опубликовано в журнале "Системы безопасности" №3/2022

Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>