Журнал "Системы Безопасности" № 3‘2022

S E C U R I T Y A N D I T M A N A G E M E N T 15 l версия, формирующая все настройки для станка, журнал для инженеров для регистра- ции вносимых изменений, ответственность за брак на инженере; l запрет инженерам вносить правки в настрой- ки для каждого заказа, исправление настроек только в случае брака, с регистрацией сделан- ных исправлений в журнале, ответственность за брак на компании; l отказ от ручного труда, журнал исправлений настроек заполняет дежурный инженер; l расширение ассортимента оправ и линз, выполнение на станке 99% заказов (эта часть не входит в указанный полугодовой интервал). Сейчас в России около девяти таких станков в пяти сетях оптик, из них четыре станка в "айк- рафт". Только в "айкрафт" труд инженеров авто- матизирован. без поэтапного подхода к проекту и в "айкрафт" до сих пор настройки делали бы вручную, так как решение поставщика для интеграции с ERP зарубежные коллеги пред- почитают покупать при наличии примерно шести станков, то есть компании потребовалось бы вырасти еще раза в полтора. Проект снижения трудозатрат на складе в какой-то момент в компании назрела потреб- ность увеличить штат комплектации либо опти- мизировать работу сотрудников. Каков бюджет? Предположили, что добавление в смену одного сотрудника позволит на год закрыть проблему. итого бюджет – расходы на двух сотрудников за 1–2 года. Сроки, понятное дело, – "вчера". Учитывая предстоящие летние отпуска, недостающих работников решили набрать, а когда эффективность склада будет повышена, сократить за счет текучки. Каковы требования? Глупо изобретать велоси- пед, поэтому начали с изучения рынка: выстав- ки, поставщики WMS, визиты на автоматизиро- ванные склады. на выходе получили несколько устраивающих нас технических предложений от интеграторов, вот только окупаемость наиболее простого варианта мы оценили в четыре года и срок реализации – ближе к году. Чтобы не отка- зываться от автоматизации вовсе, решили отка- заться от части требований и реализовать на базе имеющейся ERP следующее: l не формировать в системе отдельные доку- менты под каждую операцию комплектации заказов на производство (немного сложнее "искать концы", но реализация намного проще); l использовать адресное хранение только для зоны комплектации (ручные операции на других участках несущественно нагружают персонал); l не автоматизировать запуск инвентаризации при отсутствии товара в ячейке (если товар для заказа не найден, заказ откладывается в отдельную кучу, если не найден при пополне- нии магазина, товар пропускают – отправят в другой раз); l не хранить несколько товаров в одной ячейке (часть рядов промаркировали чаще, по раз- меру минимальной ячейки); l один товар размещать только в одной ячейке (часть товаров физически занимают несколь- ко ячеек, привязка идет по первой); l ряд других менее существенных требований также были вырезаны. При этом появилась возможность снизить тру- дозатраты склада "малой кровью". версии дора- боток получились следующими: l грубо зонировать оправы согласно ABC-ана- лизу, добавить в бланк комплектации заказов для производства зону хранения оправы, оставить комплектацию по бумажке – таков был минимально жизнеспособный продукт; l реализовать адресное хранение с точностью "модель – ячейка", вручную заполнить в ERP адреса хранения оправ, выдавать заказы на комплектацию по порядку хранения на складе; l запросить доработку интерфейса ERP для комплектации заказов на пополнение запасов магазинов при помощи ТСд, создать интер- фейс привязки через ТСд товаров к ячейкам, привязать все товары к ячейкам; l пока готовится программа для ERP, выдавать на печать форму комплектации запасов мага- зинов с сортировкой по местам хранения; l безбумажная комплектация пополнения магазинов при помощи ТСд; l запросить доработку интерфейса ERP для комплектации заказов для производства при помощи ТСд; l переход на безбумажную комплектацию зака- зов для производства. итог проекта: расширять штат не пришлось долгие годы, более того сотрудников нагрузи- ли дополнительной работой, ошибки сократи- лись более чем на порядок. Окупаемость – менее полугода, снижение трудозатрат про- исходило раз в месяц и чаще. С каждым шагом становились понятнее требования к следую- щим изменениям. Решение используется до сих пор, при этом практически прежний штат выполняет втрое больше операций, чем до автоматизации. Проект реорганизации интерфейса в рознице По мере ускорения роста сети остро встал вопрос поиска кадров для розницы. Продавцов на рынке пруд пруди, но не всякий способен быстро освоить задачу – продажу очков по рецепту кли- ента. имевшееся на старте решение сопровож- далось самописной 40-страничной документа- цией по основным процессам продавца, осваи- валась эта премудрость в процессе месячной ста- жировки, часть кадров отсеивалась из-за слож- ностей освоения. в итоге была поставлена цель: вчерашние продавцы огурцов должны завтра уметь торговать очками. никто в оптике такого еще не делал. Может быть, это невозможно? По правде говоря, я немного лукавлю. К момен- ту, когда мы задались такой целью, мы уже точно знали, что это возможно. Процесс оформ- ления очков действительно достаточно слож- ный, и в 2011 г. на оформление одного заказа требовалось от 5 до 15 мин., но к 2013 г. была проделана большая работа без замены имев- шейся системы – трудоемкость удалось сокра- тить до 2–3 мин. на заказ. дальнейшая оптими- зация требовала более значительных инвести- ций, и хотелось одновременно решить сразу несколько проблем. Как определить приемлемый бюджет? не было сомнений, что улучшать интерфейс для компа- нии жизненно необходимо, а самый бюджет- ный вариант – перевести текущее решение с текстового DOS-подобного варианта на веб- формы (с рядом ограничений, но система такое позволяла). Этот бюджет был взят за основу для оценки альтернатив. варианты перехода на дру- гие системы для оптики отпали – каждая опе- режала решение "айкрафт" в части интерфейса, но в технических вопросах столь же сильно отставала. в качестве альтернативы было реше- но попытаться использовать Odoo ERP, дорабо- тав ее для оптики. Каковы риски? Риски велики, если пробовать реализовать все разом. но опасения были купи- рованы Agile-подходом. в Odoo ERP ожили сле- дующие подпроекты: l реализован лаконичный интерфейс пополне- ния базы зрения клиентов (работа розницы упростилась, программисты освоили новую систему); l добавлен интерфейс анкетирования клиентов (повысились возможности маркетинга); l старые DOS-подобные кассы с аппаратной клавиатурой переведены на графический тачскрин-интерфейс (экономия на прежних лицензиях, ниже требования к оборудова- нию, часть продаж уже можно выполнять с планшета или смартфона, без ПК); l создан веб-интерфейс для оформления зака- зов (в каждом магазине появилось по план- шету на сотрудника, буклет по освоению нового интерфейса занимает один лист с двух сторон, почти никто его не читает – и так все понятно; инструкция встроена в систему, с ней знакомят новобранцев, дальше к ней никто уже не возвращается); l создан интерфейс для оформления редких операций (в том числе ремонта), повышены удобство, скорость, надежность системы, реа- лизована возможность безбумажной работы с клиентом; l кассовая отчетность переведена в электрон- ную форму. Это если крупными вехами, реально новый функционал появлялся несколько раз в месяц. По пути возникало море технических сложно- стей, но за счет инкрементно-итеративного под- хода все это успешно решалось. исходный бюд- жет превышен не был. Результат превысил ожи- дания. По шагам – к цели не столь важно, по какой методике реализовы- вать инновационные проекты: по каскадной модели (водопад – англ. waterfall), по методике PMBoK, по Scrum или согласно принципам Agile. в любом из вариантов самое важное, что позво- ляет минимизировать риски, – снижение требо- ваний. Об этом в иТ-мире писали и в середине 1960-х гг. ("Мифический человеко-месяц"), и в середине 1990-х гг. ("Путь камикадзе"), и в начале XXI века ("Scrum. Революционный метод управления проектами", "Скрам: гибкое управление продуктом и бизнесом"). не нужно пытаться сделать все с первой попыт- ки, стараться объять необъятное. Практичнее продвигаться по чуть-чуть, корректируя поже- лания после каждой итерации. дорогу осилит идущий, главное – верить в себя и свою команду! n www.secuteck.ru июнь – июль 2022 СПЕЦПРОЕКТ ЦифРОвизаЦия ПРОизвОдСТв и бизнЕС-ПРОЦЕССОв Ваше мнение и вопросы по статье направляйте на ss @groteck.ru