суббота, 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

четверг, 26 июня 2014 г.

О проекте автоматизации HR-процессов: есть ли границы автоматизации ручной работы? Part 6

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

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

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

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

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

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

К одним из самых трудно автоматизированным процессам относятся, безусловно, управление персоналом. Что можно автоматизировать относительно просто - это учет кадров - для этого даже созданы специальные программы: 1С, Босс-кадровик и др. Но как быть с остальными функциями HR - обучение (не только электронное), адаптация, оценка, кадровый резерв, управление талантами и пр.?

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

Единственно правильным решением в этом случае является ограниченность автоматизации - что-то все же оставлять на усмотрение оператора. Например, проведение обучения (очного) автоматизировать нельзя - все же тренинги остаются тренингами, а значит, и автоматическое завершение под вопросом. Конечно, можно "закрывать" тренинг автоматически в системе (проставлять статус) по истечению заданного промежутка времени. Но, если тренинг вовсе не состоялся из-за недобора или болезни тренера, то система все же "начнет" и "закроет" тренинг автоматически. И по отчетам проведется ложная информация. Лучше, если закрывать тренинг будет сам тренер или администратор (человек, контролирующий процесс обучения). При чем, не просто закрывать, но и проставлять перед этим статусы присутствия обучаемых, а сообщения об отметках присутствия будут уходить не только в отчет, но и руководителям сотрудников. Т.е. мы вводим ручное воздействие, полагаясь на работу тренера и его заинтересованность, но при этом вводим простое решение контроля - автоматические рассылки уведомлений, что намного проще, чем продумывать все "если" решений машины, чтобы не получилось холостой  и ложной работы.

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

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

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

To be continued...


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

понедельник, 9 июня 2014 г.

О проекте автоматизации HR-процессов. Написание бизнес-процесса под автоматизацию. Part 5.2

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

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

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

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

Поэтому, получается, что лучше, если картина будет полной и исчерпывающей и даже избыточной (но не слишком), чем неполной. Объясню подробней. Под автоматизацию можно смоделировать только алгоритм работы компьютера - то, что будет выполняться автоматически, но для человека, разрабатывающего систему, картина окажется неполной. Некоторые действия, вырванные из контекста "жизни", будут не понятны, и нельзя будет оценить целесообразность или правильность описываемых этапов и шагов. Это во-первых. Во-вторых, программирование, как ни странно звучит, также творческий процесс, и если программист понимает процесс хорошо, то он может и предложить лучшие варианты реализации, или даже проверить реализуемый процесс на адекватность и логичность - возможно, он предложит вам более интересный и простой вариант, который вы сами не увидели. Если же давать процесс разорванный и только автоматизацию конкретных действий, вы рискуете не использовать полный потенциал разработчика и получить только то, что просили. Чаще всего, это в итоге не совсем то, что вы представляли себе, так как не учли множество нюансов и особенностей разрабатываемой системы.

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

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

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

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

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

To be continued...

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