Автоматизация логистических процессов: как «пробить стену» в общении с IT-департаментом?
IT-технологии глубоко внедрились в нашу жизнь, уже невозможно представить оптимизацию бизнеса без автоматизации, считает Алена Сарапина, бизнес-консультант (PM, BPM. ITSM). На Конференции XIX Всеукраинский День Логиста она рассказала аудитории об автоматизации логистических процессов, как это происходит на практике. Как достичь понимания, «пробить стену» в общении с IT-службами? Об этом как раз и предложила поговорить докладчица.
— Я бизнес-консультант, занимаюсь оптимизацией, формализацией, регламентацией, автоматизацией и работой с IT службами, IТ департаментами. Информационные технологии глубоко внедрились в нашу жизнь, и не только в нашу бытовую жизнь, но и в наш бизнес. Мы уже не представляем оптимизацию без автоматизации. И вообще наш мир стал очень технологичным, но до сих пор мы в работе с IT службами сталкиваемся с необходимостью «пробивать стены» при внедрении автоматизированных решений. Об этом и поговорим, потому что успехов в автоматизации бизнеса добивается тот, кто умеет наладить общение с департаментами и службами информационных технологий.
Тезисы:
1. Как сформировать требования к автоматизации?
2. Как просто и легко объяснить программисту требования бизнеса?
3. Сквозной пример автоматизации логистического процесса.
Моя презентация разделена на две части: стратегическую и тактическую. Для того чтобы отстаивать свою точку зрения на автоматизацию, необходимо себя настроить на то что вы имеете право всю логику бизнеса автоматизировать. Поэтому я всем своим командам говорю два ключевых слова «понимать» и «отжимать».
Что значит «понимать»? Нужно понимать свой бизнес. Какие действия, в какой последовательности происходят, какие документы необходимы для выполнения данных действий и какие данные необходимо переносить от одного действия к другому. Это обязательные пункты, которые я всегда прорабатываю для того чтобы понять, что необходимо бизнесу.
Для понимания бизнеса существует определенные методики:
− Аудит бизнес процессов «как есть». Возможно, есть уже некоторые готовые решения, как преобразовать бизнес, какие необходимы организационные изменения.
− Внедрение процессного управления «как будет». На этом этапе схемы «как есть» необходимо преобразовать в схемы «как будет».
− Также необходимо понять уровень зрелости управленческой отчетности. Необходимо продумать, какой должна быть отчетность для принятия управленческих решений.
- Необходимо понять уровень зрелости автоматизации. Есть действия, выполняемые именно в системе, или желательно, чтобы они были в системе, есть действия, которые мы никак не можем выполнить в системе, например перемещение товаров на складе из одной ячейки в другую.
Практически у каждой компании существуют записанные бизнес-процессы, отображающие либо ситуацию «как есть», либо ситуацию «как необходимо изменить». На схеме обязательно выделяются кросс-функциональные дорожки — это роли менеджера склада, кладовщика, экспедитора, а также цепочки действий и документов, которые необходимы для обеспечения данных бизнес-процессов. Также на схеме есть специальная маркировка автоматизированного действия для обозначения уровня зрелости автоматизации определенного процесса. Есть действия, которые потенциально должны быть автоматизированы. Кросс-функциональная дорожка обязательна для того, чтобы в системе предусмотреть роли для управления правами доступа.
Отчетность для принятия управленческих решений необходимо тоже для бизнес-процессов предусмотреть, задать определенные вопросы менеджеру, который отвечает за этот бизнес-процесс, какие цели должны быть достигнуты и какой результат должен быть. Эти цели отобразить в определенной таблице Microsoft Excel для того, чтобы показать IT разработчикам.
Как понять, что готов «отжимать»?
− Решение изменений описано. Для того чтобы разговаривать с IT департаментом и с разработчиками решение изменений должно быть описано. Есть некие потребности в изменении бизнес-процессов, их обязательно нужно описывать. Потому что ваше видение может остаться просто видением.
− Ситуации алгоритмизированы «если? — тогда что?». Ни одна информационная система не понимает логику, если она не алгоритмизирована. Я рассматриваю все ситуации, которые могут быть в бизнес-процессе. Например, товар приехал на склад, его приняли. Но бывают ситуации, когда есть недостачи, или больше товара, и с ним что-то нужно делать. Эти ситуации тоже должны быть предусмотрены в системе.
Когда вы решили, что понимаете все свои бизнес процессы, вы готовы «отжимать». В общении с IT, вы должны четко понимать, как представитель бизнеса, что вы имеете право, чтобы все изменения бизнеса отображались в информационной системе. Иногда бывает так, что IT «отжимает» у бизнеса, и получается, что не бизнес диктует, как ему развиваться, а информационная система своей логикой ограничивает бизнес в развитии или в функционировании. Бизнес не должен страдать и ограничиваться логикой информационной системы.
Тактическая часть — как это делать?
Первый этап — это разработка функциональных требований для автоматизации.
Второй этап — это выбор автоматизированного решения. Это может быть выбор нового автоматизированного решения и модификация/доработка существующего автоматизированного решения.
План автоматизации:
Первый этап. Разработка функциональных требований для автоматизации (userstory). Первый шаг, который нужно сделать, это сформировать требования, то есть писать требования к каждому шагу бизнес-процесса, описать требования к документам и описать требования данных. Требований к одному шагу может быть энное количество. Необходимо описать формат и характеристику этих данных, которые будут в системе.
Второй шаг, определить для каждого требования маркировку — это критичное для бизнеса требование или некритичное (дополнительное) требование. Это делается для экономии денежных средств, то есть если информационная система по критичным функциональным требованиям не подходит, то зачем тогда вообще выбирать эту систему. Если она покрывает критичные требования, но не покрывает дополнительное требования, то такая система вполне может подойти, потому что это возможность сэкономить, мы можем минимизировать затраты на разработку и модификацию изменений этого решения. Когда функциональные требования описаны, описываются требования к каждому шагу бизнес-процесса, какие инструменты и механизмы должны быть включены в систему.
Второй этап. Первый вариант выбора — это модификация/доработка существующего автоматизированного решения. После функциональных требований необходимо сформировать задание на автоматизацию, где очень подробно прописывается каждый шаг, каждое требование шага, все документы, все данные в документах, которые должны быть, а также движение этих данных между документами. Это делается для понимания разработчика, чтобы IT департамент понимал решения, которые необходимы бизнесу. Затем необходимо написать задание на автоматизацию. Функциональное требование — это высокоуровневое требование, которое предъявляет бизнес. Для разработчика эти требования нужно перевести на понятный ему язык.
Второй шаг — определение вместе с IT службой возможности модификации/доработки. Разработчик возле каждого из функциональных требований отмечает, к чему они относятся, это стандартный функционал, доработка или модификация. Зачем это делать? Потому что стандартный функционал — это бесплатно и максимально быстро. Модификация/доработка имеют какие-то трудозатраты, имеют стоимость, и чреваты последствиями в дальнейшей эксплуатации. Потому что при обновлениях системы стандартный функционал обновляется без проблем, а обновление доработки/модификации — это снова доработка, и на это необходимо снова тратить средства и время. Поэтому лучше выбирать коробочное решение или стандартный функционал по максимуму.
Третий шаг. Определение целесообразности модификации/доработки. Необходимо выяснить какие будут трудозатраты, сколько времени займет внедрение и какова стоимость реализации решения, потому что на основании этого принимается решение о целесообразности модификации/доработки.
Второй вариант выбора — это выбор нового автоматизированного решения, длиной в пять шагов. В первую очередь, это выбор класса информационной системы. Сейчас очень много существует классов информационных систем, необходимо выбрать класс под тот функционал, который необходим компании. Для этого необходимо провести мониторинг рынка информационных систем по параметрам:
− наличие представительств/компаний-интеграторов в СНГ;
− поддержка русского/украинского интерфейса.
Затем формируется полный перечень и отбираются информационные системы в длинный список. Необходимо обратить внимание на количество реализованных проектов внедрения ИС, количество интеграторов и компаний заказчика за последние три года. В длинный список входят системы, по которым было осуществлено не менее четырех проектов за последние три года и наличие не менее чем двух компаний-интеграторов. Потому что, если не существует интеграторов, то может быть так, что некому будет делать обновления, и необходимо будет развивать собственный штат айтишников в компании.
Следующий шаг — это отбор информационных систем в короткий список. Туда попадают все системы, которые максимально соответствуют нашим функциональным требованиям и по общим требованиям, таким как безопасность данных, IT инфраструктура, количество лицензий.
И последний шаг — это выбор информационной системы и, соответственно, интегратора. На одну систему может приходиться 10-20 и больше интеграторов. Для того чтобы сделать оптимальный выбор информационной системы из короткого списка, необходимо сделать итоговую таблицу. Бизнес-консультант не имеет права на окончательный выбор интегратора, это делают представители бизнеса, либо топ-менеджмент, либо генеральный директор, либо владелец компании. Но бизнес-консультант должен предоставить независимую оценку.
Приведу в пример три варианта систем и компаний-интеграторов, которые были в последнем моем проекте. Первый вариант — полное соответствие функциональным требованиям, возможность покупки дополнительных модулей при развитии бизнеса, покрытие и автоматизация бизнес-процессов на 100%, но минусом является высокая стоимость, равная 1 млн. гривен. Второй вариант — соответствие функциональным требованиям только по критическим функциям, покрытие и автоматизация бизнес-процессов на 50%, слабые возможности интеграции с другими информационными системами. Третий вариант — это полное соответствие функциональным требованиям к информационной системе, покрытие и автоматизация бизнес процессов на 100%, бесплатное решение, но отсутствует бесплатный украинский и русский интерфейс, и отсутствует компания-интегратор для поддержки на этапах жизненного цикла. Такую сравнительную таблицу бизнес-консультант делает для того, кто делает окончательный выбор.
Читайте также: Взаимодействие грузовладельцев и грузоперевозчиков в единой электронной платформе
Портал о розничной и оптовой торговле TradeMaster.UA
По поводу размещения Ваших материалов на портале пишите на press@trademaster.com.ua
Раздел: Ринки NonFood >
Коментарі
Ваш коментар буде першим.Додати коментар
.jpg)