суббота, 28 июня 2014 г.

О проекте автоматизации HR-процессов. Выбор нотации описания бизнес-процесса. Part 7

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

Во время обучения в ВУЗе (Московском Государственном Строительном Университете, специальность "САПР в строительстве" ) я научилась алгоритмизации - навыку построения алгоритмов для написания программ. Этот навык обязателен в любом программировании. Поэтому, когда я непосредственно столкнулась с задачей моделирования, а потом и описания, бизнес-процесса, то использовала прежде всего схемы алгоритмов. Особых затруднений у меня не вызвала эта операция.

Но в моей компании, где я работала на тот момент, использовали другие нотации - специально разработанные для описания процессов. Обычно, для этого нанимают специальных специалистов - аналитиков, которые используют для этих целей специализированное программное обеспечение (например, "Бизнес-студио" или самое простое - MS Visio).

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

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

1. обучать корректно персонал - единой системе, без искажений пересказа или личного восприятия "Не знаю, как это делают другие, я делаю так! и тебе покажу как...";
2. оптимизировать процесс - описание позволяет увидеть полную картину деятельности и проанализировать, можно ли улучшить и где;
3. автоматизировать процесс - та же оптимизация, но с использованием машинных ресурсов;
4. планировать деятельность организации - на основе схемы бизнес-процесса становится понятным, какие и когда ресурсы используются и в каком количестве;
5. развивать процессы - когда видна полная картина, то и становится понятным, куда двигаться дальше;
6. управлять процессами - расставлять приоритеты, изменять или передвигать ресурсы, планировать, получать отчетность;
и т.д.

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

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

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

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

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

Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!

To be continued...


Всегда ваша
Денисова Елена,
https://www.facebook.com/profile.php?id=100004487832154
@EDDenisova