Второй шаг на пути к автоматизации бизнеса

В предыдущей статье мы разобрали первый шаг на пути к успешной автоматизации бизнеса. Там мы сформулировали главный результат, который должен быть получен в результате реализации первого шага автоматизации. Заключается он в систематизации всех бизнес процессов, их анализе, упорядочивании и разработке блок-схем функционирования предприятия. Кроме того, нам нужно назначить ответственных за появление необходимых данных в источнике данных для работающей системы. 

Второй шаг автоматизации заключается в аудите данных компании и аналитике способа их хранения

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

Что мы можем отнести к данным

Данные – это всё то, что мы используем в работе. Определение этого термина может быть различным, но мы под данными будем понимать именно всю информацию, которая требуется нам в работе. Бухгалтерия – это данные. Список товаров на витрине – данные. Список сотрудников в отделе кадров – данные. Результаты секретных испытаний или сведения о реализации рекламной компании – тоже данные! Всё это служебная информация, которая в той или иной степени участвует в работе любого предприятия.

Не стоит думать, что у маленьких компаний практически нет никаких данных. Они есть всегда. Например, даже если вы продаёте метлы на рынке, то у вас есть, как минимум, две категории данных – это данные о прибыли и данные о количестве реализованного товара.

Теперь внимание! Данные являются результатом обработки каждого конкретного бизнес-процесса. 

В предыдущем материале мы разобрали простейший бизнес-процесс продажи товара в спортивном магазине. Там у нас был оператор-менеджер-бухгалтер-менеджер. На каждой итерации в рамках реализации каждого перехода процесса на новое звено формируются данные. Так, в данном примере, оператор, который принял заказ сформировал данные о заказе, передал их менеджеру, менеджер зафиксировал информацию и сформировал данные для клиента по оплате заказа, после оплаты заказа сформировались данные об оплате, которые обработал бухгалтер, ну а менеджер обработал данные об успешной оплате от бухгалтера и сформулировал новые данные.

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

Как работать с данными эффективно

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

Для этого необходимо проанализировать все данные и систематизировать их в разные группы. 

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

В рассматриваемом ранее примере было бы логично распределить информацию по группам следующим образом (группы сочиняем на лету для примера):

1. Оператор получил сведения о заказе и внес данные о клиенте (в базу клиентов) в раздел КЛИЕНТЫ  и информацию о покупке и её составе в раздел ЗАКАЗЫ В РАБОТЕ.

2. Менеджер получил уведомление из системы о том, что в разделе ЗАКАЗЫ В РАБОТЕ появилась не обработанная запись и в ответ сформировал счёт для оплаты клиентом.

3. Сформированный счёт увидели в бухгалтерии, а при получении информации по выполненной оплате в разделе ЗАКАЗЫ В РАБОТЕ и ФИНАНСЫ ФИРМЫ появились отметки, которые увидел бухгалтер.

4. Бухгалтер дал команду менеджеру запустить заказ в работу. Менеджер отметил в разделе ЗАКАЗЫ В РАБОТЕ галочку, что на сбор.

5. Менеджер отдела покупку “счастливому” клиенту и внес данные в раздел ОТГРУЗКИ.

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

Как хранить данные или о таблицах

Испокон веков данные хранятся в таблицах. Это самый удобный и эффективный способ хранения информации. Так было ещё на заводах в амбарных книгах, так делалось в экселе, делается так и сегодня. Все современные базы данных хранятся именно в виде табличек. Загляните в любую базе SQL или любую другую и увидите множество таблиц с гиперссылками.

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

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

Ведь нарушение рабочей схемы или упущенную из виду моменты – это будущие затыки в разрабатываемой системе автоматизации. Именно поэтому, нужен хороший архитектор будущей базы данных.

На что следует обратить особое внимание

  • На первых же этапах важно выявить, кто именно и в какой мере будет заносить данные в таблицы. 

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

  • Ни в коем случае не старайтесь объять необъятное!

На первом шаге мы уже выяснили, что автоматизацию следует начинать с наиболее проблемных участков. Сбор данных следует начинать с этих же участков работы. Не стоит составлять таблицы сразу на все случаи жизни. Гораздо лучше отработать логику на простом проблемном участке. Однако, все потенциальные данные должны быть проанализированы в полном объеме хотя бы на уровне блок схем. 

Если упустить этот момент, то в дальнейшем возможны неудобные пересечения и петли, выбраться из которых тяжело будет даже опытному архитектору баз данных.

Значит, мы составляем блок схему всех процессов, а отрабатываем начиная с проблемных. Не стоит тут бояться что-то упустить. Нам важно иметь правильный скелет. Если фундаментальные процессы будут обозначены, то и сложности при дополнении будут минимальными. Гораздо более грубая ошибка – свалить всё в кучу и попытаться объединить всё в одну гигантскую таблицу без связей.

  • Двойная работа – смерти подобна!

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

Ответить

Ваш адрес email не будет опубликован. Обязательные поля помечены *