Построение процессной модели при внедрении программного обеспечения

В прошлой статье “Что такое компьютерная информационная система” я поднял важный вопрос о базовых понятиях и понимании терминологии при взаимодействии пользователя (заказчика) и программистов. Как и обещал, я продолжаю раскрывать эту тему. И хочу рассказать о правильном планировании процесса разработки и внедрения программных продуктов.

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

В принципе, о важности планирования написано очень много. И я здесь не буду повторять всем известные истины. Все просто: если вы знаете, куда вам нужно прийти и сумеете проложить верный маршрут, вы достигните цели. Если нет – увы, никто не сможет заранее угадать, куда вы в итоге придете.

«Подводные камни» планирования в сфере IT

Любой план достижения цели должен учитывать такие факторы:

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

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

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

Каждый коллектив, как и каждый человек, по-своему уникальны. И них всегда есть свои, особые потребности и пожелания. Разработку и внедрение программного обеспечения для того и заказывают, чтобы получить решение «под себя», когда существующих типовых программ оказывается недостаточно.

При планировании проекта в сфере IT необходимо:

1. Изучить особенности и потребности заказчика;
2. Четко понять поставленную задачу и учесть все пожелания;
3. Согласовать с заказчиком выбранные решения.

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

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

Компьютерная информационная система – это идея, выраженная посредством языка программирования.

 

Подробное описание и обоснование такого определения я давал в статье «Что такое компьютерная информационная система». Для лучшего понимания рекомендую ознакомиться всем, кто еще ее не читал.

Идея и выбор программных продуктов

Первое и наиболее очевидное, что нужно понимать: чтобы выбранный или созданный под заказ программный продукт соответствовали вашей идее, необходимо сочетание двух факторов:

1. Наличие самой идеи;
2. Ее внятное и однозначное описание для других участников проекта.

И на этапе однозначного и понятного третьим лицам описания идеи проекта очень полезными оказываются, так называемые, BPM схемы. Иначе говоря, графические нотации описания бизнес-процессов. Подробнее с тем, что это такое и как составляют BPM нотации вы можете ознакомиться в моей статье «Что такое бизнес-процесс и описание бизнес процесса».

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

Для описания бизнеса или выполнения какой-либо задачи могут применяться два подхода – процессный и функциональный. Об их отличиях и особенностях я также уже подробно писал в статье «Моделирование бизнеса. Основные подходы».

При поиске решения (формулировке самой идеи) многие предпочитают функциональный вариант моделирования. Он помогает для себя понять суть задачи и необходимые для ее решения инструменты. А для эффективного решения поставленной задачи и составления плана работ, как показывает мой личный опыт, оптимально подходит процессное моделирование.

Как это делают:

1. Создается графическая нотация (описание) бизнес процесса. Я рекомендую использовать формат BPMN 2.0 как наиболее продвинутый и проработанный инструмент, применение которого снижает вероятность ошибок и неоднозначных решений.
2. Идею, выраженную в виде BPMN нотации, обсуждают с заинтересованными сторонами (заказчики, пользователи, в некоторых случаях – разработчики).
3. Под согласованную идею выбирают программное обеспечение либо принимают решение о написании программного продукта с нуля.
4. Составляется план работ с учетом выбранных инструментов, решений, подробно разработанной идеи (BPMN нотации).

Как создается BPMN модель

Для успешного составления BPM нотации человек должен обладать определенными знаниями:

1. Понимать особенности работы организации (взаимодействия пользователей). Без этого воплощение идеи будет, скорей всего, содержать ошибки. В результате системой пользоваться будет неудобно или вообще невозможно.
2. Знать особенности алгоритмизации и, как минимум, основы программирования. Это необходимо, чтобы ставить корректные и реалистичные требования к программным системам.
3. Иметь навыки работы с графическими нотациями. Этот формат, как и любая инфографика, самый наглядный и понятный всем участникам проекта вариант отображения поставленной задачи.

При сотрудничестве с бизнесом или некоммерческими организациями процесс сотрудничества строится следующим образом:

1. Общая постановка задачи – формулируется руководителем компании;
2. Уточнение этапов работы и особенностей реализации – руководители и сотрудники подразделений, которые будут работать с программным продуктом.

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

Далее, полученное описание оформляется в виде графической нотации, где также присутствует несколько уровней детализации. Их число зависит от сложности системы.

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

Выбор программного продукта

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

В наше время для коммерческих и некоммерческих организаций крайне редко приходится писать программные решения «с нуля». Это дорого и долго. Тем более, что для большинства идей существуют готовые (типовые) решения, которые достаточно настроить и/или немного доработать.

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

Например, идея звучит так: «нужна автоматизация работы отдела продаж».

Этап 1. Для реализации лучше всего подходит CRM-система. Эти программные решения разрабатываются специально для отделов продаж.

Этап 2. Из всех существующих CRM нужно выбрать те, функционал которых максимально подходит под выбранный алгоритм работы (реализацию идею).

Этап 3. Выбор из составленного списка подходящих CRM заключается в изучении их дополнительного функционала: готовых решений для интеграции с другими программными продуктами, наличие встроенных полезных для идеи инструментов, соотношение цены/качества.

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

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

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

Преимущества процессного подхода

1. Человек мыслит последовательно. Одновременно продумывать несколько разных действий и охватывать несколько задач или направлений – крайне сложно. Человек мыслит шаг за шагом, решая одну за другой задачи по мере их поступления. А потому вариант воплощения идеи в виде последовательности действий – наиболее подходящий. Он позволяет продумать все детали и не пропустить ничего важного.
2. Однозначность решения и простота согласования участниками проекта. Графические нотации читаются просто, они понятны интуитивно руководителю компании-заказчика, близки к блок-схемам алгоритмизации, а потому удобны разработчикам. В итоге, их просто согласовать, а при реализации практически не возникает разночтений.
3. Формат BPMN поможет избежать ошибок. Сама среда разработки графических нотаций и простота отображения помогают вовремя заметить большинство ошибок, избежать логических противоречий и «незавершенных» процессов.

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

Больше примеров будет в следующих публикациях.