Любой организационный процесс организации должен быть направлен на повышение эффективности бизнеса. Поэтому разработка и внедрение CRM в компании - это ни что иное, как бизнес-процесс по оптимизации деятельности.
Этот процесс имеет стадию начала, завершения и носит цикличный характер. Под цикличностью подразумевается устаревание продукта CRM и замещение его новым. Как правило, развитые организации хорошо документируют свои бизнес-процессы, совершенствуют их и даже создают репозитории устаревших или шаблоны будущих разработок.
Бизнес-процессы могут составлять коммерческую тайну и быть объектом продажи. Они выражаются в текстовом или графическом виде, реализованном в программной оболочке.
Такое отношение характеризует правильное функционирование организации. Но как ведут себя начинающие компании?
Начало разработки бизнес-процессов
Разработчик, первым вопросом должен выяснить: Кто кого должен слушать при формировании первоначальных требований к бизнес-процессам?
Существуют две формы взаимодействия:
- как есть (as is) - при таком взаимодействии разработчик подчиняется требованиям заказчика и реализует все процессы, которые существуют в компании, том виде, в каком они присутствуют, без изменений (хотя, обсуждение корректив не запрещено)
- как надо (to be) - разработчик, основываясь на своих знаниях, прокладывает оптимальные маршруты документооборота и порядки совершения действий, а заказчик принимает эти схемы и следует указаниям CRM в своей бизнес-деятельности.
Во избежании спорных ситуаций по поводу принятия решений, следует сразу договориться о схеме взаимодействия.
Документальной основой бизнес-процессов могут служить:
- должностные инструкции персонала
- уставные цели и задачи компании
- положения и правила документооборота компании
- инструкции и схемы предоставления услуг и продажи товаров
- результаты маркетинговых исследований и коммерческие концепции
- рекламные материалы конкурентов
- для полноты информации, можно проводить опрос и анкетирование сотрудников компании, с целю выяснения рабочих правил и схем действий.
Полученные бизнес-знания компании классифицируют по нескольким направлениям:
- основные бизнес-процессы - направленные на получение прибыли: оказание услуг, продажа продукции
- поддерживающие бизнес-процессы - создают инфраструктуру организации, поддерживают основные процессы
- бизнес-процессы развития - обеспечивают совершенствование компании, поддерживают долгосрочные проекты
- бизнес-процессы управления - направлены на управление организацией.
Классифицировав бизнес-знания, приступают процессам формализации и написания отдельных схем.
Формализация бизнес-процессов
Для того, чтобы бизнес-идея приобрела форму бизнес-процесса, нужно определить:
- цель, которую необходимо достигнуть
- круг участвующих лиц
- сроки реализации целей и задач
- установить момент начала и завершения бизнес-процесса.
Формализация проходит некоторые условные стадии:
- текстовое представление последовательности действий - простое указание в виде списка, всех необходимых мероприятий, расчётов и иных действий
- графическое представление - формализация процессов в виде схемы, выполненной с учётом правил выбранной нотации (правил графического оформления)
- проверка условий и ограничений процессов, диверсионный анализ взаимодействий объектов - обычная логическая проверка последовательностей действий с постановкой стандартного вопроса: "Что произойдёт, если условие или действие не выполнено?"
- оптимизация бизнес-процесса - завершающая стадия формализации, в которой проверяют схему на отсутствие лишних действий и возможности разделения больших схем на подпроцессы.
Немного расскажу о нотациях.
Нотации или правила графического представления схем, содержат:
- требования к оформлению объектов соответствующими символами
- логику обозначения связей
- правила декомпозиции отдельных узлов взаимодействия.
Некоторые популярные нотации:
- нотация 1С - нотация описания бизнес-процессов в "1С:Предприятие", отражающая взаимодействия между объектами 1С-системы
- UML - является объектно-ориентированным языком моделирования и на его основе возможна генерация программного кода
- DFD - описывает логические функции, потоки данных и хранилища данных, иногда, используется для описания схем интерфейсов
- IDEF0 - основным принципом этого стандарта является декомпозиция, которая применяется при разбиении сложного процесса на составляющие его функции, стандарт может использоваться при создании больших схем с несколькими уровнями детализации
- IDEF3 - показывает причинно-следственные связи между ситуациями и событиями, используя инструмент визуального моделирования бизнес-процессов.
По-другому, их можно назвать языком моделирования и, несмотря на некоторые различия, все они подходят для формализации бизнес-процессов, также как и обычный графический редактор без всяких правил.
Главное, чтобы было соблюдено самое основное правило: представлена логика порядка совершения действий и взаимодействия объектов, необходимых для достижения конкретной цели и выполнения конкретной задачи.
Продолжение темы логики бизнес-процессов с примерами схем и некоторыми приёмами управления задачами будет в следующей статье.
автор публикации: Демешин С.В.
