Работал начальником отдела на заводе, потом стал аналитиком в IT. Вот что меня поразило
Всего каких-то 3 года назад я работал на горнодобывающем предприятии полного цикла со своей добычей, обогащением, погрузкой на ж/д-транспорт и прочими ништяками. Успел поруководить отделом, хотя начинал с рядовой позиции. А сейчас я аналитик. Или консультант, кому как удобней.
Переход с одной стороны баррикад на другую уже сам по себе непрост и интересен, но особенно подчеркну: с одной стороны ты пользователь, который страдает. С другой же: ты настраиваешь то, от чего пользователь страдает. Этот переход изменил мой взгляд на бизнес-процессы. Я увидел одни и те же ошибки с двух разных ракурсов. Это дало мне возможность увидеть основную проблему во внедрении этих ваших айтисистем: разрыв между настройкой системы и её использованием — это не техническая проблема. Скорее человеческая.
Вот основные вещи, которые могу выделить.
1. Регламент ради регламента
Когда я работал на производстве, каждую неделю выходило по два-три приказа с обновлением или введением в действие какой-то процедуры, методики, регламента и т.п. Они были тяжёлые — и по «весу», и по стилю написания. Для тех, кому посчастливилось не видеть своими глазами подобное творчество, поясню - есть такое негласное правило на многих производствах - чем более бюрократизирован и канцеляризирован текст, тем круче он смотрится перед руководством.
Только руководство, как правило, подмахивает не глядя. А рядовые сотрудники, которым спускается документ к исполнению, потом чешут репу и ведут друг с другом дебаты: что же все таки имел в виду автор? Или, что проще, подходят с просьбой: «переведи на человеческий».
Став консультантом, я понял, почему так происходит. Регламент обычно пишет человек, который никогда не выполнял описанные в нём действия. Он описывает какой-то «свой» идеальный процесс, а не реальный. И первый же случай, не предусмотренный документом, всё ломает. Регламент пишется как техническое задание, а не как инструкция для живых людей. И зачастую просто для галочки, шоб было.
2. Система живёт отдельно от реальности
Sap жил своей жизнью, а реальные ремонты — своей. Реальные, наиболее «горящие» работы без каких-либо проблем велись в обход системы. И я сейчас говорю не про хорошего механика-хомяка, у которого всегда все есть и он просто делает свое дело - ремонтирует. Скорее я говорю про то, что открытие потребностей и закрытие заказов делалось задним числом — если делалось вообще.
Вместо реального планирования своей работы механик бегал и выполнял поручения десятка руководителей: от «покрась бордюр» до «иди принимай масло на весь цех». Зачем для этого главный механик и его люди — вопрос, о котором не хочется думать в данном посте.
Став консультантом, я посмотрел на ситуацию с другой стороны. Система позволяет закрыть заказ без контрольных точек — и это не баг. Это решение, которое приняли на внедрении, потому что «так проще». А потом живут с этим годами. Система должна не наказывать за нарушение, а делать его невозможным. Не «ты нарушил регламент», а «ты не можешь закрыть заказ, пока не подтвердишь работы». И материалы для работ ты не получишь, пока не откроешь заказ.
3. Уведомления ради статистики
Уведомления о неисправностях жили сами по себе. Людям в полях это было неинтересно от слова совсем. Руководству — только с точки зрения выполнения показателей. Вчерашние студенты без проблем справлялись с созданием нужной статистики. На реальное планирование работ и ресурсов это, само собой, никак не влияло. Те же самые неисправности, только реальные, механики и слесаря продолжали держать в голове. Оставался принцип: кто «громче» на совещаниях, тот дефект и устраняется.
Как аналитик я понял: проблема не в людях. Проблема в том, что маршрут уведомления не настроен. Нет настроек системы, что критичное уведомление должно стать заказом за два часа. Нет эскалации руководителю, если оно «висит» без внимания больше суток. Система молчит — люди тоже молчат. Процесс не имеет «движителя». Должно быть автоматическое правило, которое толкает заявку дальше, а не ждёт, что кто-то вспомнит.
С ходу хотелось еще написать про мастер-данные, ведение баз данных в целом и принцип «работает - не трогай», но уже и так получилось много текста. Может, в следующий раз.
Что я понял
Как руководителя отдела меня больше всего раздражало нежелание людей работать на результат. Моя позиция обязывала не давать таким людям остановить процесс, но в то же время принести хоть какую-то пользу. Это был постоянный баланс.
А со стороны консультанта я ужасаюсь, насколько люди оторваны от реальности — и айтишники, и пользователи. Инструкции пишутся как «нажми кнопочку, чтобы кнопочка нажалась». Вместо «кнопка = полезное действие». Человек читает инструкцию и не понимает, зачем он это делает. А человек - он же ленивый, зачем ему нужна эта кнопочка? Вот он ее и не нажмет.
Аналитик настраивает процесс. Пользователь живёт в процессе. И если они не понимают друг друга, система работает на бумаге и не работает в жизни.
Я был с обеих сторон. Теперь, когда я настраиваю, я сначала спрашиваю не «как должно быть в стандарте», а «как вы реально работаете». А когда пишу регламент, представляю человека, который будет им пользоваться в три часа ночи при простое машины.
Долгое время оставался читателем, но сегодня решил написать, излить «наболевшее». Планирую писать про SAP, регламенты и бизнес-процессы — с обеих сторон. Если интересно, подписывайтесь.