Личностный рост. Автоматизация HR процессов - "удобный и красивый интерфейс"? Как Технарю понять HR?

На днях попалась на глаза обратная связь одной девушки HR о работе некоей IT системы, используемой для автоматизации HR-процессов.

У нас реально есть трудности во взаимодействии IT специалистов с "обычными" пользователями. Проблема не в том, что сами по себе специалисты IT плохо коммуницируют: надо отдать им должное, в текущих условиях крупные и успешные IT организации улучшают и развивают свою клиентоориентированность. Дело в том, что понять, что хочет HR часто бывает сложно - ведь хочется, чтобы было "красивый интерфейс" и "было удобно", но понимания собственных процессов для логического описания на бумаге у HR часто нет.

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

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

Пропасть же между IT специалистами и "обычными" людьми сейчас чувствуется все больше. Честно говоря, такие трудности испытывают не только пары IT - не IT, но и другие "профессионалы" и "не профессионалы". 

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

Размышления про себя... Большую часть своего опыта я не связывала напрямую с HR функцией, хотя и находилась всегда в подразделениях управления персоналом. По сути, всегда и выполняла функцию взаимодействия с IT контрагентами, выявляя и оптимизируя потребности HR под автоматизацию - никогда не было проблем при подаче запросов и получения обратного отклика - ни один провайдер не игнорировал звонки, письма и всегда все выполнялось более чем скоро... 

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

Сейчас я все больше погружаюсь в HR-функции: обучение, развитие, оценку.. и уже не могу отделить себя от нее. Так кто же я? Технарь или HR? 

Единственное, во что я теперь "верю" - это методология - не важно чего - обучения, оценки, процессов. 

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

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

С уважением,

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

Нужна ваша помощь, друзья! Поделитесь ассоциациями на тему: "Автоматизация? Легко!"

Дорогие друзья! 

Я начала работать над книгой "Автоматизация? Легко!"

Сюжет книги: Менеджеру среднего звена неожиданно руководство ставит задачу автоматизировать бизнес-процессы департамента, где он работает в одном из отделов. Он включается в игру под названием "Автоматизация", рискует и выигрывает.

Напишите, пожалуйста, как вы считаете, что должно быть в этой книге? О чем она?

Пишите в комментариях! Я очень жду ваших ответов! Это очень мне поможет :).

Заранее сто тысяч и больше Спасибо.

О проекте автоматизации HR-процессов. Сложные переговоры. Или как договориться ради общего результата. Part 2.1

Как часто бывает так, что успех выполнения задачи зависит не только от вас и не столько от вас, а от других людей или даже подразделений? Довольно часто сталкиваешься с ситуацией, когда в сердцах говоришь: "Ах, если бы не "Петя" и не "Вася", все давно решили бы и сделали, а он такой нехороший ставит палки в колеса и все портит!"

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

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

Чтобы переговоры были продуктивными необходимо обязательное соблюдение следующих правил:

1. Взаимоуважение

2. Желание выполнить задачу, поставленную перед участниками переговоров

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

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

Что можно сделать для выполнения этих двух правил?

Конечно, легче сказать: "Давайте будем относиться друг к другу с взаимным уважением", чем это осуществить на деле. Тем не менее для выполнения общей задачи его необходимо достичь в реальности. Для этого следует обратить внимание на личностные особенности участников переговоров - лучше до начала работы с ними. В этом поможет классификация по психотипу MBTI и методы доктора Ицхака Адизеса. Часто род деятельности косвенно указывает на личные предпочтения участников переговоров. Если говорить про рабочую группу автоматизации HR-процессов, то состав участников выглядит примерно так:

Заказчики - HR:

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

Подбор персонала - управленческий уровень преобладает P (Производители) - уделяют внимание выполнению задачи здесь и сейчас - отвечают за выполнение срочных задач в краткосрочной перспективе;

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

Системные аналитики - управленческий уровень преобладает А (Администраторы) - уделяют внимание деталям, описывают подробные бизнес-процессы, составляют БТА и ТЗ - тесно сотрудничают с подразделениями айти. 

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

Если собрать всю эту разношерстную компанию в одном помещении, то окажется, что добиться общего понимания и согласия крайне сложно: кто-то будет постоянно шумно доказывать свою точку зрения (P и E),  а кто-то саботировать молча процесс (А). К тому же разногласия могут возникнуть (и часто возникают) в одной сфере - у Заказчика. Что уж говорить о коммуникациях между разными не смежными подразделениями?

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

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

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

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

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

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

To be continued...

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

О проекте автоматизации HR-процессов. Этап 2. Подготовка системы к сдаче в эксплуатацию. Part 15

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

Поэтому процесс подготовки системы к сдаче в эксплуатацию можно ориентировочно разделить на три этапа:

1. Презентация автоматизированной системы

2. Проведение обучения

3. Подготовка инструкций работы в автоматизированной системе

Что же представляет собой презентация готового программного обеспечения?

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

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

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

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

По результатам анализа полученных замечаний необходимо принять одно из решений: 

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

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

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

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

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

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

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

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

Инструкции должны отражать полный перечень действий и операций. Рекомендуется составлять инструкции следующим образом:

1. Согласно ТЗ и Дополнительным документам составить перечень всех операций и действий автоматизируемого бизнес-процесса

2. Выполняя их, фиксировать все шаги письменно, иллюстрируя каждый шаг скриншотом.

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

4. Исправить недостатки, если они были выявлены при проверке.

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Этап 2. Тестирование разработанного программного обеспечения. Part 14

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

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

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

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

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

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

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

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

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

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Этап 2. Внутренняя или внешняя разработка. Part 13

Если вы уже приняли решение в проекте автоматизации обратиться за помощью к внешним специалистам и разработчикам, то это сообщение можно не читать! Данный текст посвящен тем смельчакам-"пионерам", кто выбрал тернистый путь самостоятельной разработки.

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

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

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

Что может быть проще - передать готовый пакет документации на разработку и спокойно ждать результата? Если бы так было возможно в действительности, это было бы сказкой, а не жизнью!

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

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

1. Приемка и согласование промежуточных результатов
2. Фиксирование всех возникающих багов и хроники их исправления с итогами
3. Подача, приемка и отработка заявок заказчика на дополнительные доработки или внесение изменений, не учтенных в ТЗ
4. Правила апробации
5. Условия передачи системы в эксплуатацию
6. Распределение зон ответственности за результат
7. Правила и условия предоставления отчетности по разработке
8. Механизмы контроля за качеством разрабатываемой программы
9. Другое

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

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

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

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

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

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

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

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

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

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Этап 2. Подготовка проектной документации. Part 12

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

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

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

Поэтому, прежде чем приступать к техническому документу, который оформлен и написан так, чтобы его понял программист-разработчик (или команда программистов), следует описать схему словами в виде требований к предполагаемой системе. Проще говоря, зафиксировать пожелания и ожидания заказчика в виде словесного описания уже разработанных бизнес-схем. Описание должно быть очень подробным и содержать требования: "Система должна позволять... , В программе должно быть то  и то, так и так... На экране в такой то момент времени при выполнении такого то условия или при нажатии такой-то кнопки должен появится определенный результат...". Этот описательный документ носит название Бизнес требования к автоматизации. (Он может носить и другое название, принятое в организации, но суть его остается прежней. Я же буду пользоваться этим обозначением, а именно сокращенным БТА.) И на основе БТА уже создается техническое задание, где словесное описание "переводится" на технический язык программистов.

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

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

1. Получить на выходе не то, что ожидали
2. Потерять возможность контролировать процесс автоматизации в части реализации
3. Потерять возможность корректировать в процессе реализации без понимания системы в целом
4. Получить споры и конфликты с программистами из-за отсутствия взаимного понимания
5. Потратить впустую ресурсы
и еще множества других неприятных сюрпризов.

Принципы описания БТА и ТЗ приводить не буду, если вы не аналитик, то это вам все равно не поможет, а если аналитик, то это вы и без меня это хорошо знаете!

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Этап 2. Реализация. Проектная и командная работа. Part 11.2

В любой организации в процессе автоматизации бизнес-процессов возникают вопросы о ее реализации:

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

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

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

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

• какие процессы уже автоматизированы?
• как реализована имеющаяся автоматизация?
• какие платформы и системы используются?
• как они взаимосвязаны (и взаимосвязаны ли) между собой?
• кто реализовывал автоматизацию - внешние контрагенты или собственные специалисты?

Далее определить, как встраивается будущая система:

• предполагается, как часть уже имеющегося процесса?
• создается как самостоятельная система, которая будет интегрироваться с другими процессами?
• это первая автоматизация в организации?

Если опыт автоматизации в организации есть, то какой он? самостоятельный или используется внешняя разработка?

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

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

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

Итак, прежде чем собрать команду специалистов, определитесь с вопросом - кто, где и как будет разрабатывать вашу систему! 

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Этап 2. Реализация. Проектная или командная работа. Part 11.1

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

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

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

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

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

1. Основной заказчик процесса (кто принимает окончательное решение по проекту);
2. Системный аналитик;
3. Программист (ы);
4. Системные тестировщики;
5. Эксперты процесса;
6. Конечные пользователи процесса (рабочая группа или представитель).

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

1. Субординация.

2. Различия функциональные

3. Занятость в своих рабочих задачах

Как скоординировать, организовать и сплотить такую разношерстную кампанию?

Более того, как правильно ее сформировать? и всегда ли есть выбор для формирования?

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Этап 2. Реализация.

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

О проекте автоматизации HR-процессов. Как все было и есть. Part 1
О проекте автоматизации HR-процессов. Установка границ процесса или начало работы с заказчиком. Part 2
О проекте автоматизации HR-процессов. Кто главный в проекте автоматизации? Part 3
О проекте автоматизации HR-процессов. Почему важно увидеть процесс целиком и как это сделать. Part 4
О проекте автоматизации HR-процессов. Общая структура процесса - верхний уровень. Part 5.1
О проекте автоматизации HR-процессов. Написание бизнес-процесса под автоматизацию. Part 5.2
О проекте автоматизации HR-процессов: есть ли границы автоматизации ручной работы? Part 6
О проекте автоматизации HR-процессов. Выбор нотации описания бизнес-процесса. Part 7
О проекте автоматизации HR-процессов: описание бизнес-процесса на едином языке. Как найти общий язык? Part 8
О проекте автоматизации HR-процессов. Как проверить правильность моделируемого процесса? Part 9
О проекте автоматизации HR-процессов. Сквозные процессы. Разграничение обязанностей. Part 10.1
О проекте автоматизации HR-процессов. Сквозные процессы. Границы влияния и действия функций. Part 10.2
О проекте автоматизации HR-процессов. Сквозные процессы. Регламенты. Part 10.3
О проекте автоматизации HR-процессов. Сквозные процессы. Part 10.4
О проекте автоматизации HR-процессов. Целостность процесса. Part 10.5


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

На втором этапе необходимо было выполнить следующие работы:

1. Полученные схемы бизнес-процесса, формализованного в нотации "Visio" или "Бизнес-студио", необходимо описать словами в виде бизнес-требований.
2. Составить техническое задание на основе бизнес-требований.
3. Разработать программное обеспечение (написать программу).
4. Протестировать разработанное ПО, внести коррективы, возможно что-то изменить.
5. Подготовить документацию для пользователей для обучения работе с созданным ПО.
6. Сдать в эксплуатацию.
7. Наладить поддержку ПО.

Об этом в следующих сообщениях будет описано подробно.

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Целостность процесса. Part 10.5

Когда я училась в университете, курсе на 4-м наш преподаватель Вячеслав Федорович Яковлев говорил о системах. О том, чтобы исследовать полностью любую систему, необходимо изучить ее как внутри, так и снаружи. И тогда, и только тогда в ней не остается загадок, и все становится ясным и понятным. Вот, почему человек наверное никогда не сможет разгадать все тайны жизни.

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

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

Получается, процессы и внутри часто запутаны и интуитивны. Что же говорить о всей картине?

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

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

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

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Сквозные процессы. Part 10.4

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

Я привожу здесь другие критерии, взятые из книги Владимира Репина "Бизнес-процессы. Моделирование, внедрение, управление", 2013г, М., "Манн, Иванов и Фербер":

Процесс можно считать сквозным, если:

-участники процесса являются сотрудниками различных структурных подразделений;

-деятельность в рамках процесса рассматривается на уровне отделов или сотрудников (операционный уровень);

-существует возможность организации контроля оперативной деятельности по процессу и полученных результатов одним руководителем;

-результат процесса важен с точки зрения достижения целей организации в целом (или существенной ее части) либо удовлетворения потребностей внешнего потребителя;

- существует возможность значительного улучшения деятельности (усиления эффектов синергии) за счет оптимизации межфункционального взаимодействия в рамках процесса.

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

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

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

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

О проекте автоматизации HR-процессов. Сквозные процессы. Регламенты. Part 10.3

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

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

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

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

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

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

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

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

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

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

@EDDenisova

О проекте автоматизации HR-процессов. Сквозные процессы. Границы влияния и действия функций. Part 10.2

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

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

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

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

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

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

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

@EDDenisova

О проекте автоматизации HR-процессов. Сквозные процессы. Разграничение обязанностей. Part 10.1

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

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

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

Поэтому, здесь есть несколько сложностей:

1. Четкое разграничение обязанностей.

2. Четкие границы влияния и действия функций.

3. Регламентируемые границы процессов - где функция начинается и где заканчивается.

4. Подтверждение, что процесс проходит через несколько функций последовательно или параллельно.

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

Рассмотрим каждый пункт отдельно.

Четкое разграничение обязанностей

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

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

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

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

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

Во всем должен быть порядок. Иначе получится, как в известной сказке Корнея Чуковского "Путаница", где все звери поменялись своими природными обязанностями.

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

@EDDenisova

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To be continued...

Всегда ваша

Денисова Елена,

https://www.facebook.com/profile.php?id=100004487832154

@EDDenisova

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

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

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

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

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

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

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

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

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

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

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

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

To be continued...

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

О проекте автоматизации 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

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

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

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

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

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

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

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

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

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

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

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

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

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

To be continued...

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