Немного про оптимизацию процессов
Немного про оптимизацию процессов
Уровень автоматизации и зависимости от информационных технологий в Корпорации ТЕХНОНИКОЛЬ можно сравнить разве что с банком или финансовой структурой. Понятно, что автоматизация не самоцель, безусловно подлежат автоматизации только периодические (повторяющиеся не реже 2 – 3 раз в неделю) процессы, прежде всего трудоемкие и ошибоемкие.
Все прочее рассматривается через призму жизненной необходимости и экономической эффективности. Зачастую вместо сложной и дорогой автоматизации достаточно просто добавить вычислительные мощности или несколько сотрудников.
Все наши информационные системы и процессы мы подразделяем на централизованные, локальные и претендующие на централизацию.
К централизованным относится то, что непосредственно влияет на основные жизненные процессы в компании: производство продукции, оприходование и отгрузку. От стабильности, надежности и ритмичности этих процессов зависит удовлетворенность клиентов, а значит, и бизнес-результат. Понятно, что требования к уровню автоматизации основных процессов у нас самые высокие.
Мы любим повторять, что основа бизнеса ТЕХНОНИКОЛЬ — «лидерство в издержках и оптимальность процессов». Оптимизация процессов начинается обычно в оптимистичном режиме .По правилу Парето, приложив всего 20 % усилий, можно решить основную массу, процентов 80, проблем, связанных с организацией движения документов, перемещением транспортных средств, оптимизацией времени ожидания погрузки и даже с оптимальностью загруженности складов. Естественно, все это в Корпорации давным-давно сделано.
Самое интересное начинается дальше. Для того, чтобы выжать максимум как из оборудования, так и из процессов, чтобы «подобрать» оставшиеся «крошки» (хороши «крошки» — порядка 20 %!), усилий приходится прилагать гораздо больше, да и задачи становятся на порядок сложнее. Именно здесь ИТ являются наиболее эффективным инструментом.
Начинаются работы по глубокой оптимизации перемещения товаров на складе (системы класса WMS), оптимизируется производство для сокращения переналадок и повышения загруженности технологических линий (системы планирования производства и предиктивные системы). Все это сопряжено с множеством математических вычислений, обработкой огромных массивов данных.
Путь этот тернист, тем более что многие системы и процессы, используемые в Корпорации, не имеют аналогов. Практически все процессы постоянно пересматриваются и изменяются. На начальном этапе развития ИТ приходилось не только быстро и гибко вносить корректировки, но и проводить полные ревизии и глобальные изменения процессов. Все это наслаивалось на строящуюся сетевую и серверную архитектуру.
! МНОГИЕ СИСТЕМЫ И ПРОЦЕССЫ, ИСПОЛЬЗУЕМЫЕ В КОРПОРАЦИИ, НЕ ИМЕЮТ АНАЛОГОВ.
Периодические проблемы с обрывами каналов связи, зависанием системы, внезапным резким снижением производительности еще 6 – 7 лет назад сильно нервировали не только клиентов (что понятно), но и менеджеров Корпорации. Как можно выполнить план по объемам отгрузки или количеству отработанных заказов, если система вдруг замедляется до скорости черепахи или, еще лучше, выдает сообщение об ошибке и зависает?
Такое положение никуда не годилось. Требовались глобальные перемены в подходах. Мелькнула даже идея (она серьезно обсуждалась) — организовать систему отгрузок в Отделе клиентского сервиса (ОКС) так, чтобы в случае сбоев в работе системы была возможность перевести на «ручной режим» оформление отгрузки продукции со складов, дабы машины на территории не простаивали и штрафные санкции не генерировали.
Веселенькая была бы картина: сотня сотрудников ОКСа, имея в информационной системе буквально всю информацию (контакты плановиков, данные по кредитам, контакты грузоперевозчиков, данные о габаритах транспортных средств, сроках, времени отгрузки, спецификации и т. д.), при отключении системы вручную лихорадочно выписывали бы отгрузочные документы. Понятное дело, не без многочисленных ошибок!
Впрочем, эта идея сделать «два шага назад», к ручному труду поклонников у нас не нашла. Решили побороться за непрерывность работы информационных систем. Кинули на это дело самых «яйцеголовых» (кстати, эта терминология активно используется менеджерами Корпорации, причем в позитивной трактовке) ИТ-специалистов.
Сначала проработали единую сетевую архитектуру для обеспечения непрерывности работы каналов связи между заводами и единым центром обработки данных, а также операторами ОКСа.
Собрали статистику и пришли к выводу, что в новой архитектуре обрыв основного и резервного канала связи является форс-мажором и происходит не чаще одного раза в год на непродолжительное время, следовательно, архитектуру передачи данных можно считать надежной.
Дальше решили разбираться с архитектурой самой централизованной системы: для начала провели аудит всех критических процессов, расставили закладки / датчики для измерения производительности модулей системы, начали собирать информацию.
Это помогло нам если не сразу открыть, то хотя бы «приоткрыть» глаза. Появилась возможность понаблюдать систему «изнутри»: что в ней происходит, когда и по каким причинам. Появилась служба улучшения слабых звеньев системы и ускорения процессов. Полностью задокументировали новые процессы в системе и унифицировали процессы в обменах. Все это дало значительный прирост производительности информационной системы и минимизировало количество аварийных остановок.
Следующая серия шагов была не менее сложной: мы двинулись в сторону разделения монолитной системы ОКСа на отдельные сервисы, что позволило:
• оптимизировать производительность;
• сократить взаимовлияние модулей друг на друга;
• повысить скорость обменов и обновления информации внутри самой системы.
Прочитали мы сейчас несколько предыдущих абзацев, и самим приятно стало — как слаженно и последовательно мы, оказывается, двигались, решая неординарную проблему. К сожалению, в реальной жизни все было не совсем так («гладко было на бумаге, да забыли про овраги»).
Это был долгий и тяжелый процесс, который осложнялся еще и тем, что бизнес постоянно обращался с конкретными, текущими и «горящими» проблемами, и зачастую приходилось все бросать и просто затыкать «дыры».
Все классические проблемы не обошли нас стороной:
• недоверие бизнеса к действиям ИТ-службы;
• нехватка квалифицированных ИТ-специалистов;
• информационный голод (команда была новая, в Корпорацию еще недостаточно вросшая);
• внутреннее сопротивление изменениям и т. д.
Зато сегодня мы практически уверены, что ручной режим в качестве страховочного в серьезных компаниях не годится. Если уж ввязались в процессы автоматизации и глубокой оптимизации процессов (с большими объемами данных, сложными вычислениями, множеством
