суббота, 26 апреля 2014 г.

О проекте автоматизации HR-процессов. Почему важно увидеть процесс целиком и как это сделать. Part 4

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

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

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

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

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

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

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

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

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

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

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

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

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

Как же объяснить это заказчику?

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

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

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

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

В-пятых верьте в себя! И все у вас получится :).

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

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

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

To be continued...

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

среда, 16 апреля 2014 г.

О проекте автоматизации HR-процессов. Кто главный в проекте автоматизации? Part 3

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

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


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

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

Это потом, когда проект ставился "на колеса", и становилось понятно, что он перспективный и уникальный (пока) в своём роде, а значит и интересный, людей, кто хотел бы внести свою лепту и мнение стало намного больше, гораздо больше. Только проблема была в том, что люди не обладали ни знаниями в тематике проекта, ни профессионализмом в области автоматизации, ни (что самое прискорбное) полным видением самой выстраиваемой системы, попросту говоря, системного мышления тоже не было. А были только амбиции за счет проекта подняться, прославиться, выслужиться, наконец.. Да еще бы так, чтобы исполнителя проекта (кто его начал и двигал изначально) по возможности вообще вытеснить и изгнать с проекта. А если не получится, то, на худой конец,  подчинить своим требованиям. Помните про ту метафору, когда исполнителю ставят задачу нарисовать 7 синих линий, где 2 из них - красные, 3 - зеленых и 1 - прозрачная? Вот, примерно также. Скорее всего, в этой ситуации были и вы, и не раз.

Как же тогда быть?

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

Вы скажете, что это проще сказать, чем выполнить. Да, непросто, но вполне возможно. Для этого необходимо:
  1. Быть, действительно, высококвалифицированным специалистом в сфере автоматизации;
  2. Обладать заслуженным авторитетом в области автоматизации;
  3. Всегда грамотно, корректно и аргументированно отстаивать свою позицию;
  4. Заручиться поддержкой высшего руководства (опять же с помощью авторитета, заработанного на успешно завершенных проектах - для проектов автоматизации это обязательное условие, т.к. в автоматизацию вкладываются значительные финансовые расходы, а результат автоматизации всегда несет высокие риски.)
  5. Не поддаваться на провокации желающих "влезть" в проект, даже если это непосредственный руководитель (это, действительно, сложно, но у вас же есть поддержка вышестоящего руководителя вашего руководителя)
  6. Не пытаться быть для всех "хорошим" парнем;
  7. Но при этом, слушать все стороны, чтобы понимать настроения и потребности (А как же! тут политика коммуникаций довольно жесткая и требует неусыпного внимания); и последнее, но самое главное!
  8. НЕ ДОПУСКАТЬ ОШИБОК! - ни одной. Цена одной ошибки - потеря авторитета и, как следствие, контроля над проектом. Поэтому, еще раз повторюсь, вы должны быть высококвалифицированным специалистом.
Вы можете (и даже нужно) консультироваться с многими, но решение окончательное принимается руководителем проекта, ответственным за конечный результат автоматизации. И в этом заключается ключ к успеху.

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

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

To be continued...

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

среда, 9 апреля 2014 г.

О проекте автоматизации HR-процессов. Установка границ процесса или начало работы с заказчиком. Part 2

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

Наиболее востребованы у меня две методологии: психологическая классификация MBTI и методология доктора И. Адизеса (http://www.ichakadizes.com/blog)

Согласно методологии И. Адизеса есть 4 основных управленческих стиля: "P" - производитель, "E" - предприниматель, "А" - администратор и "I" - интегратор. У каждого человека есть свой набор стилей, свое соотношение. И в зависимости от этого набора, такие и решения предпочитает принимать. При чем склонность может быть разного уровня - от высокого до низкого, а то и вовсе отсутствия. Единственное, чего практически не бывает - это одинаково высокий уровень у всех 4 стилей.

Коротко о них:

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

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

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

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


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

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

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

Решая коммуникационные трудности, я воспользовалась методологией И. Адизеса, учла особенности людей такого типа, подготовила ни одну презентацию с наглядным пособием, провела множество разъяснительных бесед. Также заручилась поддержкой высшего руководства, так как если приоритеты разработок спускаются сверху, то так тому и быть. Для ведения переговоров использовала техники аргументации (читала книги по аргументации Непряхина Н. (автор бестселлеров «Гни свою линию: приемы эффективной коммуникации» и «Убеждай и побеждай: секреты эффективной аргументации»).

После получения разрешения руководства, использовала техники коучинга для выявления истинной потребности подразделений обучения, а также логику построения процессов. Самое сложное было определить точку отсчета процесса, расставить зоны ответственности участвующих подразделений - где подразделение обучения, а где отдела кадров, например; чем процесс заканчивается - другими словами, определила границы процесса. Чтобы проверить правильность границ, можно ответить на следующие вопросы. Я сгруппировала их в 4 группы:
  1. С чего начинается процесс? Что произошло, чтобы начался процесс?
  2. Какие входные данные у нас есть?
  3. Что в результате должно получиться? К кому результаты пойдут? Для чего эти результаты нужны? И достаточно ли этих конечных данных, чтобы получить итоговый результат?
  4. Кто ответственен за процесс? Где зона ответственности указанной аудитория начинается, и где заканчивается, а начинается чужая?
На чем бы хотела заострить внимание. Кроме имеющихся инструментов психологии и менеджмента, нужно понимать, что при ведении коммуникации с заказчиками, да и вообще с участниками процесса, нужно использовать авторитет и не допускать каких-либо ошибок. Люди должны видеть в вас эксперта и уважать ваше мнение. Малейшая ошибка в ведении переговоров может навсегда испортить ваш авторитет и репутацию, что приведет к тому, что вы ничего не сможете донести до своих заказчиков. Поэтому, всегда нужно быть предельно корректным, а речь должна быть правильной и профессиональной - я имею в виду не сложную непонятную техническую терминологию, а правильность языка, не слэнга.

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

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

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

Если вам это интересно, подписывайтесь, чтобы получать уведомления о продолжении.
Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!
To be continued...


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

воскресенье, 6 апреля 2014 г.

О проекте автоматизации HR-процессов. Как все было и есть. Part 1

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

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

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

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

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

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

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

Трудности, с которыми я столкнулась на этом шаге работы:
  1. "Хозяин процесса" уделяет пристальное внимание краткосрочным задачам и совершенно не видит перспективу, долгосрочное развитие и процесс в целом, путает "как есть" с "как должно быть". Эта трудность не позволяет получить полную информацию от заказчика процесса сразу.
  2. "Хозяин процесса" советуется и просит совета у подразделений-клиентов - как строить процесс - клиентов много, которые имеют диаметральные точки зрения, непрофессиональные в силу не знания специфики обучения, так как работают в других сферах.
  3. Наличие конфликтов интересов заинтересованных сторон - как самого "хозяина процесса", так и его клиентов.
  4. Отсутствие понимания границ процесса - где точка отсчета и где окончание процесса.
Данные трудности разрешаются с помощью коуч-сессий, которые помогают определить истинные цели процесса, его границы и крупные составляющие процесса.

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

Трудности, с которыми я столкнулась на этом шаге работы:

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

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

Третий шаг - описание бизнес процесса в выбранной организацией нотации.

Трудности, с которыми я столкнулась на этом шаге работы:

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

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

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

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

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

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

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

Перечислю основные:

1. Стереотипное представление айти специалистов, что заказчики ничего не понимают в программировании, и потому абсолютно нелогичные люди и не могут знать, что им нужно. Поэтому автоматизировать то, что они хотят, бессмысленно.
2. Конфликт интересов подразделений информационных технологий и системных аналитиков - никто не хочет брать на себя ответственность за реализуемый продукт, а заказчику не доверяют, так как его считают не профессионалом.
3. Проблема распределения ресурсов, их преоритезация. В компании множество проектов автоматизации, и все нужны срочно.
4. Высокий интерес к перспективному проекту со стороны заказчика - множество некомпетентниых в автоматизации коллег, желающих влезть в проект и выслужиться за счет внимания руководства.
5. Невысокий статус в организации исполнителя (на тот момент,я была в должности рядового менеджера), что влечет за собой:
  • много ступенчатую вертикальную коммуникацию через несколько уровней руководителей, а это подобно испорченному телефону;
  • отсутствие рычагов воздействия и мотивации при коммуникации с другими подразделениями и исполнителями;
  • отсутствие авторитета для руководителей подразделений айти и аналитиков.
6. Нежелание руководства использовать чужой опыт, в т.ч. успешных провайдеров.
7. Внутренняя политика компании и личные взаимоотношения.

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

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

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

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

Если вам это интересно, подписывайтесь, чтобы получать уведомления о продолжении.
Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!
To be continued...

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