четверг, 31 июля 2014 г.

О проекте автоматизации HR-процессов. Как проверить правильность моделируемого процесса? Part 9

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

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

Когда же, выполняется заказ (в данном случае модель процесса под автоматизацию), то очень важно своевременно получать обратную связь. В противном случае, разработчик оказывается в темном туннеле без спасительного света впереди: никто в организации не скажет точно, правильно ли ведется описание.

Какие же маяки помогают не сбиться с пути?

Конечно, ключевая роль отводится изначальному снятию потребностей заказчика. 

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

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

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

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

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

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

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

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

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

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

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

To be continued...

Всегда ваша
Денисова Елена,
@EDDenisova

пятница, 11 июля 2014 г.

О проекте автоматизации HR-процессов: описание бизнес-процесса на едином языке. Как найти общий язык? Part 8

Как часто бывает, что заказчик не может четко сформулировать запрос программистам на разработку? Довольно часто, если не почти всегда. Тем не менее они являются единственными клиентами разработчиков - иначе для кого они работают?

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

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

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

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

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

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

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

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

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

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

To be continued...


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