Три мысли про внедрение систем автоматизации

Возможно, эта часть будет для многих очевидна, но я всё же напишу. Иногда к автоматизации прибегают, чтобы получить новые возможности, иногда — чтобы увеличить мощность. Приведу два очень похожих, но очень разных примера. Компания №1 хочет внедрить CRM (Customer Relationship Management – система управления взаимоотношениями с клиентом) для связи в одном месте всей информации от клиента и про клиента, чтобы перестать терять информацию по заказам. Компания №2 уже каким-то образом аккумулирует информацию, но тоже хочет внедрить CRM, чтобы сократить трудоёмкость её сбора.

У второй компании повышен риск автоматизации бардака. Автоматизация того, как система работает сейчас, очень заманчива. Есть ожидание, что такое внедрение может пройти относительно гладко, так как поменяется формат, но не суть того, что делают люди. Но если система работает по одному и тому же «регламенту» больше некоторого, то высок риск, что мы продолжаем «обрезать края у стейков», хотя сковородка уже стала больше (отсылка к шутке, в которой три поколения по традиции обрезают края у стейков, хотя истинная причина в том, что у прабабушки была маленькая сковородка и большие куски мяса).

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

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

Что плохого во внедрении чужих правил в чужой последовательности? Допустим, сами по себе правила довольно неплохие, и решают распространённые проблемы. Сейчас заниматься улучшениями очень модно. Часто можно слышать, что компания хочет внедрить какие-то практики по причине того, что лучшие представители отрасли их используют. Но в таких улучшениях иногда забывается, что приоритет устранения проблем определяется пропорцией между выгодой и трудоёмкостью устранения этой проблемы. И вот эта пропорция для разных систем может быть очень разной. И даже если на большом промежутке времени системы придут к единому виду, их путь может быть очень разным.

В одной компании предприняли попытку внедрить на производстве одну очень известную и распространённую ERP-систему (система управления производством). Реальная потребность заключалась в приоритизации производственных заказов — это информация о том, какой заказ нужно делать в первую очередь, какой — во вторую, и так далее. Оказалось, что для внедрения приоритизации также необходимо изменить работу склада комплектующих и начать учитывать крепёж (болты, шурупы, гайки) с точностью до одной штуки. Казалось бы, правильное изменение. Должен же быть учёт. Но в реальности это изменение застопорило внедрение системы и работу производства.

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

До внедрения ERP крепёж учитывался с точностью до упаковки, пусть это будет +/-100 штук для каждой позиции крепежа. Излишки плохи тем, что занимают место и деньги. Если — с точки зрения финансов и площадей, — мы можем себе позволить эти +/-100, то мы вполне можем обеспечить достаточный уровень наличия без учёта каждой штуки. Это будет хорошим решением для нашей системы. Однако внедрение ERP требовало исправления несуществующей проблемы, несмотря на то, что затраты на её устранение не превышали выгоду.

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

Спустя год времени и несколько миллионов рублей компания так и не внедрила ту ERP. Проблема с учётом крепежа была далеко не единственной. Несмотря на потраченные ресурсы, руководство смогло принять решение отказаться от внедрения и переключилась на создание собственной системы под себя.

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

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

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

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

Розничная дистрибуционная компания. Нам нужно было ускорить приёмку поступающего товара и передачу его на полки в магазин. У нас было два очень похожих склада и магазина. У обоих стояла одинаковая система, примерно одинаковый объём поступающих товаров, равный штат, но один склад был физически намного больше. Большой склад мог позволить себе хранить товар на складе по две недели. Маленький склад понимал, что если не выносить товар на полки магазина в течение пары дней, то им просто некуда будет складывать следующую поставку. После нескольких безуспешных попыток объяснить, почему компании так важно сократить срок приёмки, решено было просто урезать площадь входного склада.

Вчера была консультация с компанией, которая занимается производством и дистрибуцией собственной продукции. Последний год ребята наводили порядок внутри, что позволило им увеличить мощности, а сейчас решили заняться продажами. Один из пунктов плана по улучшению продаж — внедрение CRM-системы. Команда видит ближайшей задачей описание регламентов работы. Дальше эти регламенты можно будет автоматизировать и внедрить.

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

Зато с первой частью всё намного проще. У сотрудников компании уже есть запрос на единую информационную базу, сейчас это — чат, которым не слишком удобно пользоваться и тем, кто вносит, и тем, кто пользуется внесённой информацией. При этом сомнений в необходимости обмена этой информацией нет. Чтобы упростить внедрение и ускорить получение первых результатов, начать можно с самого простого. Мы решили, что первым шагом нужно просто перенести сбор информации из чата в CRM. Здесь проблемы могут возникнуть, если вместе с переносом мы решим ещё и расширить перечень вносимой информации. Так что нужно быть аккуратным с обязательными для заполнения полями и не пытаться съесть слона сразу целиком. Лучше ограничится теми параметрами, которые собираются уже сейчас.

Такой первый шаг будет довольно просто внедрить. Основные выгоды, которые мы ожидаем, связаны с двумя изменениями: перестанем терять информацию по клиенту и сможем увидеть статистику по клиентам. Даже очень ограниченная статистика позволит нам чуть лучше понимать, где у нас сейчас больше болит и какой процесс в первую очередь стоит доработать и автоматизировать.

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

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

01/ История о том, как за 6 месяцев мы сократили время выполнения заказов в два раза (на самом деле быстрее) [почитать]

02/ Что такое эффективность? [почитать] [посмотреть]

03/ У вас нет выбора. Либо вы управляете ограничением, либо оно управляет вами [почитать]

04/ Теория ограничений — это серебряная пуля? [почитать]

05/ Теория ограничений и проектное управление. Что за диагональный буфер? [почитать]

06/ Если это решение, то в чем проблема? Шесть слоев сопротивления изменениям [почитать]

07/ Теория ограничений. Голдратт. Одна история применения [почитать]

08/ Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас) [почитать] [посмотреть]

09/ Парадоксы финансовой мотивации [посмотреть]

Мой телеграм-канал, где я оповещаю о новых заметках и делюсь короткими инсайтами и мыслями, которые не попадают сюда. Ещё там можно обсуждать идеи и смотреть на ТОС с разных сторон вместе с другими