Автоматизация процессов повышает эффективность организации, ускоряет процессы, помогает оперативно отвечать на запросы клиентов. Сотрудники меньше времени тратят на различные бюрократические процедуры, поиск и передачу информации, что благоприятно сказывается на производительности и снижает себестоимость работ. Кроме того, IT-системы автоматически собирают большой объем данных, позволяя на практике реализовать «управление на основе KPI».
Но, несмотря на это, многие компании малого бизнеса продолжают использовать мессенджеры и таблицы в Excel для организации выполнения работ. Почему так происходит? Я вижу три причины.
1. Разочарование и негативный опыт
Часто слышу жалобы о том, что ранее компания уже пыталась автоматизировать процессы, но не получила никаких преимуществ от внедрения системы. В таких ситуация я обычно спрашиваю: а какой именно результат вы планировали получить?
Ни одну систему автоматизации нельзя рассматривать как универсальный способ решения задач бизнеса. Если раньше диспетчер пересылал заявки техникам через Телеграмм, а теперь пересылает через FSM — систему управления выездными сотрудниками, не используя других ее возможностей, то, конечно, никаких преимуществ компания не получит.
Проблема в том, что после пары неудачных попыток автоматизации сотрудники крайне негативно воспринимают любые нововведения. Возрастает сопротивление, а иногда возникает и сознательный саботаж. Люди даже не хотят тратить время на изучение новой системы, предпочитая работать как раньше в табличках и мессенджерах.
Очень важно еще на старте определить все цели автоматизации и функционал системы, необходимый для их достижения. Важно привлекать к разработке целей автоматизации сотрудников, объяснять как именно должна помочь IT-система в работе каждого из них и компании в целом.
2. Использование неподходящих инструментов
Сейчас на рынке появилось огромное количество новых игроков, о которых еще вчера никто ничего не слышал. Руководители не хотят разбираться в этом многообразии и часто отдают предпочтение «знакомым» вендорам. Но не факт, что их выбор будет оптимальным для решения задач всей компании. Конечно, и Битрикс и 1С можно использовать и для автоматизации сервиса, но это все равно, что при сборке модели автомобиля из кубиков Лего пытаться сделать колеса и двигатель из тех же кубиков. В теории можно, но на практике лучше взять готовые детали.
На старте автоматизации важно разработать техническое задание (ТЗ) с описанием функций, выполняемых различными IT-системами и их интеграций. Не имея опыта, разработать ТЗ сложно, а консультанты и интеграторы просят немало денег за такую работу. Хорошее решение для малого бизнеса – использовать готовые шаблоны и примеры, а также обучающие курсы.
Самостоятельная разработка ТЗ требует времени, но позволяет глубже погрузиться в тему и привлечь к решению задач и выбору IT-системы ключевых сотрудников. В дальнейшем это поможет снизить сопротивление при внедрении и лучше использовать возможности выбранного решения.
3. Страх экспериментов «на живом бизнесе»
Есть такая поговорка у инженеров «не тронь то, что работает», но и оставить все как есть не получится, потому что без автоматизации компания не сможет конкурировать ни по цене, ни по качеству сервиса. Тем более что большие компании уже повсеместно внедряют системы автоматизации, сокращая свои расходы и улучшая качество сервиса.
Прежде чем изменять или автоматизировать процессы, они проводят их моделирование и имитацию выполнения в специальных программах для бизнес-архитекторов. В результате серьезно снижаются риски, можно оценить сроки возврата инвестиций в автоматизацию, устраняются «узкие места» в процессах, и в первую очередь автоматизируются или перераспределяются функции перегруженных сотрудников. Без привлечения специалистов выполнить моделирование процессов сложно, а работа консультантов стоит дорого, поэтому сейчас консалтинговые компании ищут способы снижения трудозатрат и стандартизации работ в подобных проектах.
Перспективным выглядит использование отраслевых шаблонов для быстрой адаптации под конкретную компанию. Поделюсь интересными выводами результатов исследования из книги «Свод знаний по управлению бизнес-процессами BPM CBOK 4.0», с которыми я и мои коллеги полностью согласны:
- Компании конкурируют между собой за счет 5% своих бизнес-процессов, которые реально отличают их от конкурентов.
- Еще 15% — важные ключевые процессы, которые поддерживают конкурентное преимущество.
- Остальные 80% процессов не являются уникальными. Они соответствуют стандартным отраслевым практикам.
Исследователи считают, что нет смысла использовать сложные и затратные методы оптимизации и разного рода инновации по отношению к стандартным отраслевым процессам. Необходимо концентрироваться в первую очередь на 20% процессов – дифференциаторов. Оптимизация и оцифровка именно этих процессов позволяют быстро получить видимые полезные эффекты для бизнеса, такие как рост лояльности клиентов и повышение прибыли.
Таким образом, концентрируя усилия внешних экспертов на 20% ключевых процессов, можно существенно снизить затраты на моделирование и имитацию процессов перед их изменением в реальном бизнесе. Остальные 80% процессов могут проектироваться на основе отраслевых шаблонов.
Вывод
Если раньше проектирование процессов и в целом процессный подход были жизненной необходимостью и преимуществом больших компаний, то сейчас наблюдается тенденция к построению эффективных процессов и в малом бизнесе.
В целом есть основания считать, что в ближайшие 2-3 года препятствия, мешающие автоматизации малого бизнеса, будут успешно устранены и небольшие сервисные компании получат возможность повысить свою эффективность до уровня лидеров своих отраслей.
Читайте также:
Вот это и может оказаться нетривиальной задачей. Достаточно часто попадаются факты использования откровенно устаревшего софта, который при этом работает. Если бы его портирование удавалось легко и просто - вопросов бы не было, но по тому софту, что производится, видно, что до оригинальных версий он пока не дотягивает. Просто в силу того, что часов меньше затрачено было, чем инвестировали оригинальные вендоры.
В отношении "железа" - в СССР была собственная программа по его разработке и развитию, но потом перешли на западную архитектуру. По современному "Эльбрусу" и сопряженным решениям попадаются пока противоречивые отзывы. Может оказаться, что разработки в других странах станут опережать локальные технические решения - не IBM уже, конечно, но некий условный Qing Bao, и снова может быть сменен вектор.
Что будет востребовано в ближайшие годы - мы узнаем по факту, но пока уже можно делать прикидки. В этой всей ситуации мне нравится, что стал создаваться реестр софта, и критическая инфраструктура начала на него переходить. Но мне также видится, что бОльшая централизация и ускорение всей связки (и критический софт, и локальное "железо") могли бы сильно снизить риски как разработчиков софта, так и закупающих IT-решения предприятий. Как следствие - ускорилась бы и автоматизация бизнес-процессов.
Конечно. Как обычно.
Вы о чём?
В своё время на эту тему было принято несколько стратегических решений. Собственные разработки универсальных ЭВМ второго поколения были свёрнуты (вспомним Минск, Урал, Наири, БЭСМ...). А новые семейства ЭВМ (включая ЕС и СМ со всей периферией) разрабатывали и производили несколько министерств и несколько стран в рамках СЭВ, плюс академические институты.
Эльбрусы - изделия сложной судьбы. Не будем о грустном. Никогда массово не производились.
О переписывании ПО моя оценка дана выше.
Для выпуска локального железа нужна - для начала - локальная микроэлектронная промышленность. То есть целая отрасль, не считая смежников, производящих высококачественные расходные материалы, компоненты и системы. Когда-то в СССР такая была. По моим оценкам, конкурентоспособность сохранялась примерно до середины 80-х. Тогда, кстати, и был запущен в полный рост Экспресс.
Один новый современный завод для выпуска чипов последнего и следующего поколений сейчас стоит десятки миллиардов - это для тех, у кого в руках уже есть соответствующий технологический процесс. Счастливых обладателей таких технологий и R&D в мире примерно 2. Даже Intel в их число уже не входит. И доступ к технологиям такого уровня уже несколько лет назад стал вопросом большой политики и причиной торговых войн, ограничений и запретов. Слово "эмбарго" многим хорошо знакомо.
Здесь я имел в виду то, что бизнес предпочитает использовать тот софт, который был куплен, "до последнего". Так, вспоминается кейс 2015 (!) года, когда парижский аэропорт Орли временно закрылся из-за сбоя Windows 3.1 (!). Мне еще периодически попадаются надстройки для Excel 2003, которые неправильно работают в более поздних версиях программы. Встречалась и отрисовка бизнес-процессов в BPwin 2002 года, потому как привыкли к интерфейсу.
А во второй части я говорил именно про новые разработки. Тот же обсуждавшийся в соседней ветке сегодня "МойОфис" - достаточно хорошее решение, но не может пока полностью заменить Excel. Как любой Mercedes - это не просто цена комплектующих и работы, это еще и капитализированное время, потраченное на наработку технологии. Портировать базовый функционал можно, но российский IT-рынок слишком долго шел в фарватере мировых вендоров, и за несколько лет предложить полные аналоги софту, который развивался десятилетиями, просто нельзя. А вот что само локально развивалось сопоставимое время - получает качество, вполне сравнимое с мировым - здесь я, например, про САПР КОМПАС-3D могу сказать. Очень достойный продукт вышел.
Если что-то неплохо работает и решает задачу - зачем это менять?
Ваши примеры, скорее, не о ПО, а о больших конфигурациях, где немало рабочих мест, которые морально и физически устарели, но замена потребует слишком существенных для владельца затрат. Это обычно не техническая проблема.
Я видел много проблем с постоянными требованиями продления поддержки Win XP для корпоративных и государственных заказчиков, иногда - национального масштаба. Или вспомним недавний ажиотаж с переписыванием старых приложений на COBOL.
Есть хорошие продукты - и все остальные. Если авторы ПО любого назначения действительно глубоко понимают проблематику и могут решить задачу, остальное уже проще.
Могу сказать, что технологии и инструменты, используемые - например - для решения основных задач нашими банками, на достаточно высоком уровне. То же - о системах и продуктах ИБ. Есть и другие области с хорошими коробочными и заказными продуктами.
Я вижу проблему не в переписывании уже имеющегося - это только консервирует отставание, а в концентрации усилий на создании действительно нового, полезного, качественного и конкурентоспособного хотя бы на нескольких важных направлениях от системного ПО до приложений. Огромная работа, но хорошие примеры были, есть, и их не так мало.
Кстати, с ленты новостей о том, кто собирается стать лидером в IT в ближайшие годы.
По прогнозам аналитиков компании Gartner, глобальные расходы на IT в 2025 году вырастут на 9,3% и достигнут $5,74 трлн. При этом Индия нарастит траты в этой категории сразу на 11,2% — больше, чем кто-либо в мире. В следующем году в стране могут потратить около $160 млрд на инфраструктуру и проекты из этой сферы. На что конкретно пойдут индийские инвестиции, кто планирует вложиться в индийский IT-сектор и в каком состоянии он находится сегодня?
Нам, в свою очередь, нужно найти своё место в решении собственных задач и мировом разделении труда.
Странно, что никто не назвал крайне низкую способность управлять изменениями рядовых организаций в числе причин провала проектов автоматизации. Далеко не везде есть сервисный подход.
По моему мнению, это - первое, что нужно выстроить в организации. Остальное приложится.
Статья отлично поднимает проблему, почему малый бизнес боится автоматизации, даже понимая её преимущества.
Несколько практических моментов, которые могут усилить эффект автоматизации:
Сначала оптимизируйте, потом автоматизируйте. Любая IT-система — это инструмент, а не решение всех проблем. Если процессы хаотичны, их автоматизация просто зафиксирует хаос в цифровом виде. Поэтому перед внедрением полезно провести аудит текущих рабочих схем и устранить узкие места.
Четкие критерии выбора системы. Универсального решения нет, но хороший старт — составить ТЗ, в котором чётко прописаны ключевые требования: какие задачи должна решать система, какие интеграции нужны, какой уровень гибкости требуется. Это поможет избежать разочарований.
Сотрудники должны видеть выгоду, а не просто «новую систему». Автоматизация встречает сопротивление, если персонал воспринимает её как дополнительную нагрузку. Вовлечение сотрудников на ранних этапах, демонстрация реальных выгод для их работы и гибкий переход — всё это снижает саботаж внедрения.
Отличный материал, который заставляет задуматься о том, как правильно подходить к автоматизации, а не просто внедрять ради моды!