Форум Сообщества Аналитиков
Дисциплины => Консалтинг и Внедрение => Тема начата: alex-golder от 27 Июля 2009, 19:42:00
-
Хочу открыть новую тему именно о человеческом факторе факторе во внедрении (не важно чего: процессов, автоматизированных систем и т.д).
Моя оценка по результатам внедрений наводит на размышления о 80%... то есть успех внедрения зависит на 80% от человеческого фактора и только на 20% от технологий и инструментов ;D
Проиллюстрировать ЭТО хочу своей статьей (вернее зарисовками).
В основу статьи положены реальные примеры внедрений. Возможно, это не очень "форматная" статья, но тем не менее мне важны отзывы и комментарии. Так что прошу не стесняться 8)
Читаем и комментируем http://anovichkov.msk.ru/?p=104 (http://anovichkov.msk.ru/?p=104)
PS Возможно, по результатам обсуждения будет продолжение статьи...
-
Хорошая статья, интересная. Не зря ссылка на неё уже неделю на главной странице uml2.ru висит. :)
-
Ну 100% - это наше всё. Хот, на самом деле, не совсем всё зависит от человеческого фактора. И зачем ждать профессиональных конференций ???
Предлагаю добить тему здесь (в смысле - набрать материала для конференции :) )
-
По-моему, это также зависит от того, на каком уровне находится процесс внедрения согласно шкале CMM.
Чем ниже уровень, тем больше зависимость от человеческого фактора.
Если внедрение типовое, что соответствует уровню Difined, то процент успеха/неуспеха где-то 50/50.
-
Можно сказать и немного по-другому :)
На каком уровне КУЛЬТУРА в конкретной организации...
Кстати, можно придумать шкалу влияния человеческого фактора в зависимости от уровнея CMMI 8)
-
"Пара бывших прапорщиков угробит любой ISO, внедренный на предприятии" (с) byur :-) ... Саша - можешь меня в статье цитировать!
-
Юр, при внедрении и одного прапорщика достаточно ;D
-
Хм.. вообще вы знаете... а ведь это мысль!! Точно!
Большие человекоподобные роботы спасут отцов и матерей отечественного анализа!
осталось только ПО соответствующее написать (хы-хы, ну вот опять человеческий фактор...)
Если серьезно - это замечательно, что многострадальная ИТ хотя бы местами созрела для обсуждения человеческого фактора. Значит, лет через 10, может, таки доберутся до профориентации и подготовки специалистов к работе с людьми (а не только с методологиями).
Сроки мне не нравятся. Хояется хотябы лет 5 :)
Ну к тому времени, глядишь, и службы по персоналу будут работать в свом большинстве с персоналом, а не вакансиями :)
-
Хм.. вообще вы знаете... а ведь это мысль!! Точно!
Большие человекоподобные роботы спасут отцов и матерей отечественного анализа!
осталось только ПО соответствующее написать (хы-хы, ну вот опять человеческий фактор...)
Если серьезно - это замечательно, что многострадальная ИТ хотя бы местами созрела для обсуждения человеческого фактора. Значит, лет через 10, может, таки доберутся до профориентации и подготовки специалистов к работе с людьми (а не только с методологиями).
Так для чего рождаются методологии, обобщается огромный опыт, разрабатываются ПО для ведения проектов?
Только для того, чтобы увеличить вероятность успеха внедрения.
Я соглашусь с вам только в том, что полностью исключить человеческий фактор нельзя. Даже на самом высоком уровне зрелости внедрения методологий.
-
...Никаких процессов у организации нет. Правда, руководство пребывало в уверенности их присутствия...
Хотел бы развеять такое расхожее мнение очень уверенных в себе консультантов и внедренцев.
Если компания/организация/предприятие существует на рынке некоторый период времени, продает свою продукцию (чем бы она не являлась), а тем более если "сама компания сверхуспешна" - процессы в компании есть.
Более того процессы есть всегда!
Вопрос какие? с точки зрения оптимальности, с точки зрения эффективности и т.п.
-
Печень лучше поставить по Google Chrome. Меньше глючить будет.
Людей я не исключаю. Впрочем, чем меньше человеческий фактор на производстве - тем лучше качество.будет. Например, токарные станки полностью автоматизируют. Пишут под них программы и загоняют чертежи.
Но внедрение и вообще проект - это не производство. Пока не научились полностью автоматизировать внедрение проекта. Но полностью в хаос превращать нельзя. Поэтому придумали всякие шкалы CMM для того, чтобы с Initial перейти в Repeatable, из него в Defined и всякий раз есть что развивать. Также были придуманы всякие PMBoK, PRINCE2 и т.д.
Вдумчивую беседу тоже можно построить соглавно какому-то шаблону, чтобы не упустить ничего из вида. Но человеческий фактор отметать нельзя.
-
Пока не научились полностью автоматизировать внедрение проекта. Но полностью в хаос превращать нельзя. Поэтому придумали всякие шкалы CMM для того, чтобы с Initial перейти в Repeatable, из него в Defined и всякий раз есть что развивать. Также были придуманы всякие PMBoK, PRINCE2 и т.д.
Нет, не поэтому, а для того, чтобы снизить риски и повысить вероятность достижения нужного результата.
Переход с одного уровня на другой нужен не сам по себе, а как возможность лучше контролировать некоторые потенциально проблемные точки в своей деятельности (в частности, в проектах).
Если Вы обратите внимание на содержание процедур, рекомендуемых этими стандартами, то окажется, что большинство из них (если не все) относятся не к техническим вопросам предметной области, а к управлению.
Посему (вслед за более учеными людьми) берусь утверждать, что пока проекты будут выполняться людьми, пресловутый человеческий фактор будет действовать всегда, и полностью "автоматизировать внедрение проекта" не удастся никогда.
-
Раньше не думали, что компьютер будет играть в шахматы лучше человека.
Чем больше будет преобладать отношение к управлению не как к искусству, а как к технологии, тем меньше будут риски плохого окончания проекта.
Как раз PMBoK'у не хватает техники. Это все равно, что закручивать шуруп с помощью плоскогубцев, когда можно купить электрический шуруповерт.
Стандарт стандартом, но в умелых руках он превращается в инструмент. Человеческий фактор будет действовать всегда, но чем меньше он будет влиять, тем меньше риски.
-
Человеческий фактор будет действовать всегда, но чем меньше он будет влиять, тем меньше риски.
...и тем меньше прибыль.
-
Прибыль, равно как и норма прибыли не падает относительно других компаний, а вот количество заказов возрастет при правильной рекламе своих достижений.
-
Прибыль, равно как и норма прибыли не падает относительно других компаний, а вот количество заказов возрастет при правильной рекламе своих достижений.
Термин "количество заказов" как бы намекает нам, что речь идёт о заказной разработке.
И совершенно закономерно, что именно в этой области компании-аутсорсеры внедряют RUP (потому что уже нахлебались "стихийных" методов), сертифицируются по ISO и CMMI (ибо заказчики хотят некоторых гарантий и предсказуемости), обучают своих сотрудников и даже открывают собственные учебные центры (так как осознают наконец важность и принципиальную неустранимость человеческого фактора), и в конце концов начинают активно использовать и пропагандировать гибкие методы разработки (потому что теперь могут себе это позволить, вырастив специалистов высокой квалификации). :)
А кроме того, мир IT не сводится к заказным проектам. Всегда найдётся какой-нибудь гугль, который взорвёт рынок, не заморачиваясь "технологией управления", а делая упор на этот гадский человеческий фактор.
Со временем, конечно, и он разжиреет и одряхлеет, создаст свои пятнадцать-двадцать уровней менеджерской иерархии, формализует собственные процессы, консультанты сделают себе состояния на "технологии управления гугля", лемминги будут копировать его опыт, и так до тех пор, пока не придёт кто-нибудь ещё.
-
У Гугла и у Яндекса и у другой интернет-компании описаны эти все процессы. Я так думаю.
Уж точно они подсчитывают количество обращений к своим сервисам таким, как gmail и mail.yandex.ru и как бы невзначай подсовывают свою рекламу. Так и живут.
Вот придумывание своих сервисов - процесс очень неформализованный. Здесь-то невозможно поставить на конвейер процесс создания новшеств. Хотя, используешь Гугл - создается впечатление, что как раз у них конвейер и он не собирается останавливаться.
Какой бы неформальный процесс не был - все равно есть техника создания документации без шаблона - как самая простая техника формализации знаний.
-
Моя оценка по результатам внедрений наводит на размышления о 80%... то есть успех внедрения зависит на 80% от человеческого фактора и только на 20% от технологий и инструментов ;D
Проиллюстрировать ЭТО хочу своей статьей (вернее зарисовками).
Вообще, из текста статьи мне, например, непонятно, откуда взялось такое соотношение "80 на 20"? Оно, конечно, считается стандартным и много где оправдывает себя, но здесь возникает резонный вопрос: только ли оказал негативное влияние человеческий фактор? Может, все-таки в приведенном примере не меньшую роль сыграла (как уже писали здесь выше) общая корпоративная культура? Может в предлагаемом уравнении все-таки не хватает переменных?
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.
Простите, а вы уверены, что это всегда является аргументом для заказчика?;) Я вот, например, только с такими ситуациями и сталкиваюсь, когда цели не только отсутствуют, но они никому и не нужны, а потому несоответствие целям вряд ли может являться аргументом. В конце-концов, если бы такое несоответствие можно было бы использовать в качестве аргумента, то можно ли было бы говорить о влиянии человеческого фактора, по крайней мере, в той степени, как в указано в обсуждаемой статье?
Хотел бы развеять такое расхожее мнение очень уверенных в себе консультантов и внедренцев.
Если компания/организация/предприятие существует на рынке некоторый период времени, продает свою продукцию (чем бы она не являлась), а тем более если "сама компания сверхуспешна" - процессы в компании есть.
Более того процессы есть всегда!
Вопрос какие? с точки зрения оптимальности, с точки зрения эффективности и т.п.
Ну, я думаю (и, наверное, многие со мной согласятся), что когда мы говорим о наличии/отсутствии процессов, то имеем в виду, что они описаны (задокументированы) / не описаны (не задокументированы). Далее... под процессом все-таки как-то принято понимать некую утвержденную последовательность действий в той или иной ситуации (конечно, есть и более точные определения, но здесь этого будет достаточно для иллюстрации). Во всех ли организациях, с которыми приходится иметь дело при внедрении инструментов или программных систем, мы можем обнаружить процессы в виде задокументированной процедуры?;) Я такое встречала только в одной организации и это была крупная западная компания.:)
-
Ой сколько всего написано ;D
Зря я все таки год не давал ходу данной зарисовке ::) Так как считал, что она может быть двояко истолкована, так как описывая негативное воздействие человеческого фактора на реальном примере я рискую как консультант потерять лицо в глазах читателей (все равно кто-нибудь, что-нибудь не так поймет).
Слава Богу, что что в сообществе аналитиков таких людей почти нет :D
Коллеги, хочу обратить еще раз внимание на мой первый пест в теме. История, поведанная в зарисовке не есть пример одного внедрения, а есть попытка обобщить, накопленный за 10 лет внедрений, опыт общения с __человеческим фактором__
То есть это совокупность негативных факторов, собранных в одном месте, связно описанных так, чтобы большинство специалистов\консультантов\внедренцев\заказчиков и прочих увидели в этой истории себя ;)...
Еще хочу заметить, что в статье нет рецептов "как сделать правильно", или вообще - в статье нет раздела выводов... он и не подразумевается, так как мне хотелось вызвать интерес и втянуть в дискуссию...
У меня есть предложение попытаться вернуться к человеческому фактору, возможно у вас есть примеры, сверх моих, когда что-то и как-то упиралось в этот человеческий фактор (может есть истории из жизни?)???
Когда то, еще будучи студентом, мне попалась книга по педагогике... Очень неформатная книга. Она представлена в виде мемуаров, где автор сначала описывал ситуацию, а потом разбирал ее "по косточкам" и говорил что и почему было не так.
Мне очень понравился данный формат изложения.
По результатам данного форума мне бы хотелось выпустить уже не эссе, а статью (расширенную и дополненную), которая бы строилась по шаблону:
1. Описание фактора
1.1 Рациональное объяснение как избежать подобного риска, как его снизить
1.1.1 Контр пример (из реальной же практики). Как это было успешно решено, или описание ситуации, когда этот фактор не оказал влияния
Товарищ Boatman почти раскусил мою идею ;D
Теперь попробую дать ответы на некоторые сообщения:
Ситуация очень сильно перекликается с проблемами в моих проектах.
Хочу предложить уточнение: дело в той стороне человечекого и управленческого фактора, которая касается выстраивания отношений по итогам разрешения конфликта интересов.
Ниже представлены
- мое представление процесса внедрения в каком-то приближении;
- критика по ходу процесса внедрения, описанного в статье - разбор по пунктам. Я заранее приношу извинения, если задену автора. Я сам внедренец, все описанные проблемы и ситуации испытал на своей шкуре и точно так же прогибался в отношениях с заказчиком. И не факт, что это не повторится, так как дело не только в умении, но и в реальной силе позиции.
- И дальше хотелось бы обсудить варианты, как сделать лучше.
Выше уже все сказано.
А задеть автора очень сложно. Хотя, скажу по-другому: автора можно попытаться задеть и даже скомпромитировать, но только во благо дискуссии ;D
Какие этапы необходимо пройти, чтобы было все ОК:
1. - определить ЗС (заинтересованные строны, их потребности и интересы, включая иррациональные)
2. - определить решаемую проблему (что хотят купить)
2а - определить целевое назначение системы (цели и показатели).
3. - определить решение, включая плетки и пряники, согласующие интересы ЗС
4. - определить цену вопроса: во что это все выльется не только по деньгам, но и по организационно-технической подготовке
5. - подписать заказчика на цену вопроса, включая его обязанности касательно каждой работы по плану
6. - работать по плану, в том числе:
6.1. -- настроить и пуско-наладить ПО
6.2. -- написать и утвердить инструкции и регламенты (второе очень важно)
6.3. -- обучить людей
6.4. -- прогнать их через опытную эксплуатацию
6.5. -- перевестись в промышленную, включая официальный ввод регламентов, при этом, если одна система заменяет другую сломать старую систему напрочь (стереть, отформатировать :) ), чтобы ее нельзя было никак использовать.
Согласен с логикой на все 100%. Имея за плечами не один десяток проектов по внедрению могу сказать, что данный набор шагов верный и правильный. Только есть одно "но" - для достижения цели можно пользоваться разными методами и подходы будут разными.
В реальной практике внедрения человеческий фактор играет ключевую роль при выборе стратегии внедрения. А если посмотреть вглубь, то оказывается, что человеческий фактор (он же менталитет) складывается из:
1. сектора рынка (банкинг, софтверная компания, телеком, отраслевая компания (нефтянка, металлургия), ОБОРОНКА)
каждый из факторов влияет на план (так как менталитет в разных секторах разный)
2. размер компании
чем меньше размер компании, тем менее формализованные методы в ней используются
3. РЕГИОН внедрения (или, если хотите, национальный менталитет)
Например, есть регионы, где очень большое уважение к старшим, даже если этот старший и старше-то на 2 дня :)
Если в такой проект с нашей стороны пойдет молодой специалист, то его просто не будут слушать (мальчишка, что с него взять)
И так далее и тому подобное. То есть, выбирая план работ (еще до подписания контракта) выбирается некая стратегия действий исходя из вышесказанного.
Теперь посмотрим, что сбойнуло и на каких этапах:
1. Вроде, ЗС определили, точнее по тексту статьи не скажешь, но думаю там проблем нет.
2. Проблемы описаны. Немного смущает то, что "сама компания сверхуспешна, что позволяет бизнесу смотреть сквозь пальцы на чрезмерные издержки отдела ИТ."
Когда деньги текут рекой, инструментом является лопата, а не калькулятор. (с) Мы наблюдаем риск преврашения проекта в распил бюджета. Но это всего лишь риск.
2а. О целевом назначении не сказано - это настораживает. Один из основных рисков данного проекта.
3. Решение определили не очень... Ни плеток ни пряников и, в первую очередь для ЛПР. И это видно на седующем этапе.
4. Я думаю, смету посчитали - это не проблема, а вот требования к заказчику определили не до конца.
5. Здесь стали видны проблемы предыдущих 2х этапов:
- "Заказчик мягко намекнул, что процессы ему выстраивать не надо." - в чем проблема, денег пожалели?
- "Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать" - надеюсь, его заставили положить эти процессы на стол в виде диаграмм, утвержденных регламенов и инструкций и доказательств того, что эти регламенты исполняются?
- "Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”." - иными словами очень хотелось заработать (не до жиру), по этому пришлось идти в проект на условиях заказчика (сам так попадал).
- "Пришлось взять расписку об ответственности за неуспех и приступить" - это хороший вариант для зарабатывания деннег. Для пользы дальнейшего процесса можно было грузить обязательствами "обязательно есть то, что заказывали, что заказывали четко задокументировать в спецификации".
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.
Попробую по пунктам :)
2. Я бы сказал по-другому - пока стоимость нефти или газа такова, что можно нагнать толпу неэффективных прапорщиков (привет, Юра), то это так и будет. На самом деле это проблема всех отраслевых компаний, в которых отдел ИТ- вечный проситель денег, а софт, внедряемый в основное подразделение (в бизнес) вечно виснет. Вот бизнес время от времени хочет как то улучшить прозрачность отдела ИТ, уменьшить количество багов... итд. И выделяет с барского плеча деньги на проект.
Причем, не всегда подраспильных.
2а Еще мысль-ремарка. Иногда бывают субподрядные проекты, в которых цели ставит генподрядчик. В таких проектах человеческий фактор может и за 100% выползти ;D ;D ;D
3,4 ну история так и показана :)
ок
5. Тут интереснее
- "Заказчик мягко намекнул, что процессы ему выстраивать не надо." - в чем проблема, денег пожалели?
Возвращаемся к рыночному разделению компаний. Если проект относится к оборонке, то, в 99% случаев есть все нормативные документы... и общие положения, и положения о ролях, и регламенты. И в таких проектах нужно взять и сделать как написано.
Такой заказчик не всегде хочет платить денег за глубокое предобследование и выстраивание процессов.
Да, может и денег пожалеть.
Если провести аналогию с корпоративной культурой, то она есть в любой компании. Отсутсвие культуры - тоже культура ;D
- "Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать" - надеюсь, его заставили положить эти процессы на стол в виде диаграмм, утвержденных регламенов и инструкций и доказательств того, что эти регламенты исполняются?
Что называется, не будем переходить грани светского разговора ;D
В большинстве случаев, если заказчик говорит, что у него есть ФОРМАЛИЗОВАННЫЙ процесс, то мы просим его показать.
- "Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”." - иными словами очень хотелось заработать (не до жиру), по этому пришлось идти в проект на условиях заказчика (сам так попадал).
Даже не знаю, что написать...
Наверное, кому-то и не нужны. А так, вообще, это очень сильный аргумент со стороны заказчика.
Лично для себя я готов сделать многое для заказчика, если это не противоречит в дальней перспективе _ЕГО_ же интересам. Классический вопрос: если человек стоит с завязанными глазами перед пропастью и хочет сделать шаг вперед... разрешу я ему это или нет? 8)
- "Пришлось взять расписку об ответственности за неуспех и приступить" - это хороший вариант для зарабатывания деннег. Для пользы дальнейшего процесса можно было грузить обязательствами "обязательно есть то, что заказывали, что заказывали четко задокументировать в спецификации".
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.
Ой! А как можно по-другому?
Роль расписки вполне играет _ПИЛОТНЫЙ_ проект
6-6.4
Золотые слова. Всем бы заказчикам в уши. На практике, внедрение новой системы взамен существующей (тем более если разработчики, ее поддерживающие являются сотрудниками компании), всегда сопровождается сложностями. Договор в этом случае прикрывает нас, но не гарантирует отсутствие человеческого фактора
6.5
Чтож вас так на бюджете заклинило ;D
Ну нету в этом гипотетическом примере откатов. Говорю как автор эссе... не подразумевалось там такого фатора.
Есть хороший анекдот про гребцов... Надо будет премировать менеджеров и уволить за неудачу админа для остарски...
А если без шуток, то количество систем внедренных на бумаге слиишком велико, чтобы об этом не говорить.
Какие следаны выводы автором:
И тут не все просто. Помимо формальных связей (начальник - подчиненный) есть (и еще как есть) неформальные (брат, сват, родственник, сестра, жена), которые могут вести далеко __наверх__. Придумать пряники и кнуты для такого специалиста, который является в равной степени некомпетентным и бессмертным очень сложно...
Тут я открыт для обсуждения особенно. Может у кого есть способы воздействия на подобных персонажей (варианты устранения родственников не рассматриваются).
И прошу отметить, что ЭТОТ человеческий фактор НЕ ВИДЕН до заключения контракта... Мало того, он даже проявится в проекте не сразу... Вот в моей истории были примеры компаний, где запрещалось на работу брать родственников... Но их было посчитать по пальцам одной руки (руки трехпалого ящера) ;)
Может на стадии подписания договора экстрасенсов приглашать? Не знаю... ???
Какие сделаны выводы мной:
Опять бюджет ;D ;D ;D
Хочу чтоб был учтен фактор неформальных связей. И фактор выполнения проекта на подряде.
В остальном вопросов нет. Такая точка зрения имеет место быть и бывает.
Уф...
Дальше отвечу телеграфно. Цитировать очень неудобно
"идти ли в проект, если видишь, что он закончится не очень успешно, но деньги заплятят" - это тема отдельного разговора и на этот вопрос статья не отвечает (расклад по вопросу не ясен).
Иногда бывают непопильные проекты.
Всегда неясно будет проект успешным или нет.
Никто заранее не знает что и как будет....
В том, что сказано далее все верно:
Делать сразу промышленное внедрение с закрытыми глазами в рамках предприятия (самоубийство чистой воды)
Для этого есть пилотные проекты (пилотный проект, подобно НИОКР, подразумевает как положительный, так и отрицательный исход)
И только после "пилота" все принимается опытно-промышленную и потом в промышленную эксплуатацию. Тут все верно.
(есть же масса методов внедрения: горизонтальные, вертикальные... итд)
В развитие темы и для подолжения данной темы дам ссылки (на дополнительную критику):
1. Презентация с конференции Training Labs 2008 http://cmcons.com/presentation/tl_cc_cq/ (http://cmcons.com/presentation/tl_cc_cq/)
Там как раз есть тема про типы внедрения
2. Человеческий фактор в обучении при внедрении http://cmcons.com/articles/course/trainings_strategy/ (http://cmcons.com/articles/course/trainings_strategy/)
3. Тоже эссе на тему как правильно внедрить http://cmcons.com/articles/analitika/cool_deploy/ (http://cmcons.com/articles/analitika/cool_deploy/)
Вроде все.
Спасибо за пост. Готов при доработке данной статьи взять в соавторы ;D
-
Ладно, еще секрет открою ;D
Это все (включая ссылки) были рабочие материалы для книги. Я еще собираюсь сделать несколько эссе (выдрать материалов из книжки), но вот я пока не уверен, что она будет пользоваться спросом... Хотя, опять же, дискуссия говорит об обратном.
Возможно тема и верная :)
-
Как раз PMBoK'у не хватает техники. Это все равно, что закручивать шуруп с помощью плоскогубцев, когда можно купить электрический шуруповерт.
Стандарт стандартом, но в умелых руках он превращается в инструмент.
Думаю, что это не PMBOK'у не хватает техники (его-то как раз практики пишут, см. список авторов), а его имплементаторам. Сами же пишете про умелые руки. Так что руки (да и голову) пока никто не отменял, собственно, это ключевой тезис в разговорах о человеческом факторе. Как пишут в книжках "Хорошее программное обеспечение создается людьми. Так же как и плохое. "
Или может быть книгу?... :)
Хорошо будет продаваться... :)
не факт, к сожалению. хотя хороших книг у нас катастрофически мало.
По результатам данного форума мне бы хотелось выпустить уже не эссе, а статью (расширенную и дополненную), которая бы строилась по шаблону:
1. Описание фактора
1.1 Рациональное объяснение как избежать подобного риска, как его снизить
1.1.1 Контр пример (из реальной же практики). Как это было успешно решено, или описание ситуации, когда этот фактор не оказал влияния
Почему только форума? Непонятно желание ограничить себя в каком-то мирке, пусть довольно амбициозном, но тем не менее узком.
Между прочим, всё уже придумано до нас. Про влияние человеческого фактора (который, кстати, может иметь не только отрицательное влияние, но и положительное) написано несколько довольно известных даже у нас книг, навскидку приходят на ум: Peopleware Демарко и Листера, книга с подобным названием (The Peopleware Papers) Ларри Константина.
Если есть, что сказать нового - было бы очень полезно иметь такую книжку. Впрочем, для самовыражения и сам факт неплох.
По классификации рисков посмотрите Рассела Арчибальда, правда у него приведены риски, связанные не только с человеческим фактором.
Да и с примерами придётся непросто.
-
Мне кажется, публика любит панацеи.
Они позволяют и не отказываться от природной лени (т.е. продолжать работать в том же духе, под "работать" я подразумеваю также "думать" в том же духе), и не брать на себя ответственность. Фиг ли. В книжке прочитал. Умные люди написали. Я не виноват, что не сработало (опять-таки возвращаясь к вопросу о голове и руках).
Ну-ну, добрее к людЯм надо быть. :) Никакая книжка не заменит личный опыт, конечно. Но хорошая книга поможет найти правильный путь.
Тот, кто ищет правильный путь, часто не боится и ответственности. А кто боится, тот и не ищет.
-
Между прочим, всё уже придумано до нас. Про влияние человеческого фактора (который, кстати, может иметь не только отрицательное влияние, но и положительное) написано несколько довольно известных даже у нас книг, навскидку приходят на ум: Peopleware Демарко и Листера, книга с подобным названием (The Peopleware Papers) Ларри Константина.
Если есть, что сказать нового - было бы очень полезно иметь такую книжку.
Мне тоже долгое время казалось, что нужно стремиться перечитать все книжки, которые есть, прежде чем что-то пытаться изобрести... но жизнь оказалась такова, что всех книг не перечитаешь, а действовать как-то надо... Это я к тому, что само по себе утверждение о том, что "всё уже придумано до нас" несколько спорно, хотя и не ошибочно. Это раз. А два - хорошо, книг написано много, но ситуация от этого коренным образом не меняется... Почему? Может, потому что кричать нужно громче - чтоб услышали? Это я к тому, что лишнее упоминание в прессе о влиянии в том числе и человеческого фактора при внедрении, будет вовсе не лишним.:) И три - все перечисленные вами книги - книги зарубежных авторов... Лично у меня сложилось такое впечатление, что не все западные методы применимы для российской действительности, и часто в западной литературе просто не возможно найти рецепты для различного рода специфических проблем, свойственных многим именно отечественным предприятиям.
-
Они позволяют... не брать на себя ответственность. Фиг ли. В книжке прочитал. Умные люди написали. Я не виноват, что не сработало...
А знаете, к сожалению, действительно бывают ситуации, когда лучше не брать на себя ответственность.:) (Я искренне завидую тем, кому не доводилось с ними сталкиваться!) И дело даже не в том, что лень, а в том, что тем, кто такую ситуацию создал, им-то хорошо, они так и так сухими из воды выйдут, а вот отвечать-то тебе придется... Реальный пример: у софтверной организации 2 активных проекта, по одному имеется четкий план, согласованный с заказчиком, по второму - лишь смутное представление о том, что вот эти вещи по-любому должны быть сделаны. Куратором второго проекта является начальник подразделения анализа, куратором первого - ведущий аналитик. В итоге начальник, будучии извещенным о наличии согласованного с заказчиком плана по 1-ому проекту и предупрежденный куратором этого проекта, перебрасывает запланированных на него людей на 2-ой проект... В итоге: летят сроки по 1-ому проекту, из-за отсутствия четкого плана срывается также и 2-ой проект, но вся ответственность за проблемы 1-ого проекта перекладывается этим же самым начальником на куратора, который находится в его подчинении и в общем-то и сделать-то ничего не может... Вот так вот :)
-
Дело не в "перечитать все книжки", а в том, что если какая-то вновь написанная книжка будет в сотый раз (пардон) пережёвывать темы, обмусоленные в предыдущих книжках (из-за того, что автор не удосужился ознакомиться с ними или поработать тщательнее над проблемой), ее просто никто не купит, тем более что сейчас о содержании (не об оглавлении) книги можно узнать до покупки.
По поводу неизменения ситуации у меня есть своё личное мнение. Заключается оно в отсутствии критической массы, знакомой (хотя бы просто знакомой) с литературой. ЛюдЯм кажется, что проще и дешевле будет сначала самому попробовать наступить на грабли. Но как говорит один мой знакомый: Опыт хорошая школа, но только дураки не учатся ни в какой другой.
Конечно же очередное упоминание о роли человеческого фактора лишним не будет (что мы и имеем в рамках этого обсуждения). Так что, наверное, да, нужно и кричать тоже. Вопрос: о чём? От прописных истин люди быстро устают, всем обычно нужны конкретные советы, но советы без соответствующего контекста тоже бессмысленны.
В отношении применимости западного опыта в нашей российской практике от себя могу сказать, что он вполне работает. Никакой особой специфики, "свойственной именно отечественным предприятиям", просто нет - это выдумки.
-
А знаете, к сожалению, действительно бывают ситуации, когда лучше не брать на себя ответственность.:) (Я искренне завидую тем, кому не доводилось с ними сталкиваться!) И дело даже не в том, что лень, а в том, что тем, кто такую ситуацию создал, им-то хорошо, они так и так сухими из воды выйдут, а вот отвечать-то тебе придется... Реальный пример: у софтверной организации 2 активных проекта, по одному имеется четкий план, согласованный с заказчиком, по второму - лишь смутное представление о том, что вот эти вещи по-любому должны быть сделаны. Куратором второго проекта является начальник подразделения анализа, куратором первого - ведущий аналитик. В итоге начальник, будучии извещенным о наличии согласованного с заказчиком плана по 1-ому проекту и предупрежденный куратором этого проекта, перебрасывает запланированных на него людей на 2-ой проект... В итоге: летят сроки по 1-ому проекту, из-за отсутствия четкого плана срывается также и 2-ой проект, но вся ответственность за проблемы 1-ого проекта перекладывается этим же самым начальником на куратора, который находится в его подчинении и в общем-то и сделать-то ничего не может... Вот так вот :)
и никто ничего не сказал в лицо такому "начальнику"? послать его в сторону йужного полюса, например. типа, ты куратор, я куратор - полномочия одинаковые, иди лесом.
как вариант, собрать свою команду и всем вместе уволиться. (хоть я и не приветствую коллективных хождений по мукам)
-
и никто ничего не сказал в лицо такому "начальнику"? послать его в сторону йужного полюса, например. типа, ты куратор, я куратор - полномочия одинаковые, иди лесом.
как вариант, собрать свою команду и всем вместе уволиться. (хоть я и не приветствую коллективных хождений по мукам)
Говорю же: завидую тем людям, которые могут позволить себе такого рода решительные поступки! При других обстоятельствах, пожалуй, так и бы сделала - в смысле увольнения... :) В лицо - да, сказано было... толку-то? Уроки выучены не были, продолжилось изо дня в день наступление на одни те же грабли!
-
В отношении применимости западного опыта в нашей российской практике от себя могу сказать, что он вполне работает. Никакой особой специфики, "свойственной именно отечественным предприятиям", просто нет - это выдумки.
Думаю, это тема отдельного разговора.:) Подозреваю, что мы говорим о разных вещах относительно западных методов и отечественной специфики.
-
Как говорит мой другой знакомый: не надо бояться.
Я с ним полностью согласен. Если не брать на себя ответственности, то нельзя и пробиться куда-то, зато можно получить неоценимый опыт. В данном случае он очевиден - конфликт интересов штука нехорошая.
-
Подозреваю, что мы говорим о разных вещах относительно западных методов и отечественной специфики.
Думаю, что нет. Я ожидаю, что подразумеваются способы "попросить" "наших" людей, сделать что-то, чего они не хотят делать.
-
Главное, не бояться ее брать :)
Это часть правильного подхода к делу - та, которая касается настроя.
Здесь и говорить не о чем! Согласна целиком и польностью :)
-
если одна система заменяет другую сломать старую систему напрочь (стереть, отформатировать ), чтобы ее нельзя было никак использовать.
Меня терзают смутные сомнения о целесообразности и корректности данного мероприятия... А как же, в конце-концов, обсуждаемый человеческий фактор?;) На сей раз со стороны разработчиков. :) Почему-то не считается зазорным отслеживать версионность артефактов проекта и делать бэкапы, а как систему старую - так сразу стирать напрочь - не дай бог кому придет в голову ей воспользоваться! А если мы, в смысле, разработчики, забыли (ну да, и такое бывает...), пропустили, не придали значения какой-нибудь важной функции, которую выполняла старая система? Например, потому что этой функцией пользовались не так часто, а только в исключительных случаях? Да мало ли что! И вот у заказчиков возникла необходимость срочно ей воспользоваться?... А вот, например, сменить пароли на вход в старую систему и позволять ее использовать только с письменного разрешения ответственного лица - это да, можно... Правда, здесь опять возвращаемся к человеческому фактору. ;D
-
Попробуйте привести конкретный пример: какая система была, на какую заменили, какие функции забыли. И мы сможем посмотреть в какие проблемы выливаются 2 варианта:
- дописывание функций,
- обеспечение работы новой системы с вкраплением функций старой.
Интересная задача!:) Собственно, я изначально не случайно об этом заикнулась - есть у меня такой пример. Надо только будет его оформить, причесать... Как только, так сразу - выложу. :)
Но сразу хочу оговориться - я имела в виду все-таки ситуацию дописывания в конечном итоге "забытой" функции. Просто на дописывание уходит время, а воспользоваться надо здесь и сейчас - вот тогда и может пригодиться старая система... А в целом, с вашими аргументами по поводу наличия входов/выходов и необходимости возможной интеграции, да, согласна. :) Но сама постановка задачи интересна, надо попробовать рассмотреть 2 возможных варианта.
-
Без всяких выводов приведу два примера внедрения ИС, когда использовалась и новая система, и старая.
1. Банк переходил на новую АБС. Полный переход со всеми филиалами занял три года, причем один год головная контора работала сразу в двух системах. Полноценно работала - весь рабочий день сотрудники работали в старой системе, а затем вручную(!) все те же данные вводили в новую систему - заводили документы, открывали сделки и т.п. Причем часто уже после окончания рабочего дня. Специально для этого вводили две смены. Конечно это был ад для сотрудников, но банк был региональный, сотрудникам попросту было невыгодно уходить из банка - выбор банков маловат, а з/п хорошая. Поэтому ворчали, но работали.
Насколько я знаю, причиной выбора такого метода было желание руководства уменьшить риски внедрения.
2. Банк переходит на новую АБС. Процесс все еще идет, уже лет семь как (сейчас может и восемь). Эксплуатируются обе системы, интегрированы по самое не балуйся - если что-то сделать в одной системе, аналогичное действие автоматом производится и в другой. Баланс каждый день сводится в обеих системах, идет копейка в копейку. Изначально все сотрудники работали в старой системе, а программисты писали интерграцию к новой. Постепенно (по мере роста качества интергирующего решения, а также по мере привыкания пользователей) стали переходить на работу в новой системе. При этом в старой системе постепенно отключали возможность ввода данных в различных модулях. Причем только возможность ввода - отчеты, к примеру, можно было делать. Двигаются с внедрением очень не торопясь, народу участвует в этом мало, все силами штатного ИТ Банка (их там человек пять).
Причина выбора такого метода - желание главного айтишника (он член правления Банка) уменьшить риски внедрения.
Мне по-человечески нравится второй путь.
Но у него есть минусы - во-первых, нужно время (почти неограниченное), во-вторых, нужно административное влияние для того, чтобы суметь продавить такое "неспешное" внедрение.
-
".. о человеческом факторе факторе во внедрении (не важно чего: процессов, автоматизированных систем и т.д).".. пока компании будут заниматься ВНЕДРЕНИЕМ, вместо оптимизации бизнеса с использованием информационных технологий всё так и будет, и во всем всегда конечно будут виноваты люди ;D
Пока будет отношение не IT для людей, а люди для IT ничего не поменяется :)
Эдвард Деминг описал данную ситуацию очень правильно - "98% проблемы в организации, дефекты изделий, работ или услуг зависят не от людей, а от системы и определяются присущими ей недостатками." ;)
-
2 S.V
Не знаю, чем уж вам так не угодил термин "Внедрение". ??? Насколько могу судить, обычный процесс включающий в себя набор подготовительных действий, необходимых для начала работы с новой ИС / инструментом. Т.е. по сути, все необходимые мероприятия по оптимизации бизнеса должны проводиться раньше, если и должны. А то, что они часто не проводятся, к внедрению никакого отношения, получается, не имеет.
И сама идея статьи, насколько я помню (впрочем, уже могу и ошибаться), заключается не в том, чтобы показать, что виноваты люди, а в том, что при определенных обстоятельствах слишком многое будет зависеть от каждого конкретного человека.
-
... а в том, что при определенных обстоятельствах слишком многое будет зависеть от каждого конкретного человека.
Вы бы предпочли, чтобы от вас зависело поменьше? Или вы предпочтете, чтобы всё зависело именно от вас, а не от каждого конкретного человека? Или пусть все происходит само собой, независимо ни от кого?
Не вижу ничего дурного во влиянии человеческого фактора при внедрении. Внедрение - это услуга, ее качество во многом определяется взаимодействующими лицами, а не только процессами. Многие услуги автоматизируемы, но это не значит, что мы удаляем из процесса человека. Мы меняем участников и перераспределяем ответственность.
Например, вы можете оплатить счета в банке, где удовлетворенность услугой будет зависеть от вежливости и профессионализма банковского сотрудника, или воспользоваться банкоматом, где ответственность за корректность операции будет лежать на вас и может быть чуть-чуть на разработчиках ПО для этого банкомата.
Но будет ли успешное внедрение банкоматов, принимающих оплату, проще внедрения новой системы для сотрудников банка? Или менее зависимым от человеческого фактора? И почему мы говорим о человеческом факторе только на стороне клиента, а не на стороне исполнителя? ;)
-
Эдвард Деминг описал данную ситуацию очень правильно - "98% проблемы в организации, дефекты изделий, работ или услуг зависят не от людей, а от системы и определяются присущими ей недостатками." ;)
Насколько я помню он говорил о 94% :)
-
Не знаю, чем уж вам так не угодил термин "Внедрение". ??? Насколько могу судить, обычный процесс включающий в себя набор подготовительных действий, необходимых для начала работы с новой ИС / инструментом. Т.е. по сути, все необходимые мероприятия по оптимизации бизнеса должны проводиться раньше, если и должны. А то, что они часто не проводятся, к внедрению никакого отношения, получается, не имеет.
Название статьи говорит само за себя "Человеческий фактор во внедрении процессов и инструментов или где лучше приживаются инструменты?"
и далее речь идет о факторах.. "оказывающих негатив на процесс внедрения.."
Как раз о том что перед внедрением нужно проводить мероприятия по оптимизации бизнес-процессов (а уже потом решать что нужно автоматизировать а что нет) в статье нет ни слова. За то пишут о том что руководство компании такое плохое и не понимает то что им говорят :)
Конечно если руководству наглядно не показать где и за счет чего повысится прозрачность процессов и эффективность, то разговаривать с бизнесом будет очень сложно. Так в чем же тогда тут "человеческий фактор"? :)
Эта фраза говорит сама за себя.."Никаких процессов у организации нет. Правда, руководство пребывало в уверенности их присутствия. ". Интересно если у организации нет НИКАКИХ процессов, то как она функционирует? ;D
Так что, то что не проводятся мероприятия по оптимизации БП компании к внедрению как раз имеет очень близкое отношение. :)
И сама идея статьи, насколько я помню (впрочем, уже могу и ошибаться), заключается не в том, чтобы показать, что виноваты люди, а в том, что при определенных обстоятельствах слишком многое будет зависеть от каждого конкретного человека.
В любых обстоятельствах все будет зависеть от людей. Иногда напрямую, а иногда и косвенно. Но все действия, которые приводят к тем или иным результатам совершают люди :)
Вот отсюда и такие утверждения..
"Это были объективные критерии, рассмотрение которых было бы неполным без таких мощных субъективных как:
1. Нежелание переходить на новую технологию, так как она осуществляет более глубокий контроль над деятельностью исполнителя
2. Элементарное саботирование…"
1. Вопрос а зачем людям переходить на новую технологию? им кто-то продемонстрировал ту выгоду которую они получат в результате внедрения этого нового ПО? Рядовой сотрудник осознал что ему дают удобный инструмент для выполнения его функциональных обязанностей, который ему поможет более эффективно их выполнять? :)
2. То же хороший пункт. Особенно если учесть, что в результате внедрения большинства систем, эти системы не повышают эффективность работы конкретного сотрудника, а приводят к тому что выполняемый сотрудником процесс усложняется. Очень часто такие внедрения приводят к тому что рядовому сотруднику придется вводить кучу дополнительной информации для формирования разной отчетности, которая лично ему не нужна. Так что удивительного, что сотрудники сопротивляются ВНЕДРЕНИЮ такого вот ИНСТРУМЕНТА? :) Как вы считаете если сотрудник убедится что внедряемая система позволит ему быстрее, удобнее и качественнее исполнять свои обязанности, он будет саботировать процесс? :)
-
И почему мы говорим о человеческом факторе только на стороне клиента, а не на стороне исполнителя? ;)
+100 ;D
-
Насколько я помню он говорил о 94% :)
Не буду с вами торговаться по поводу 4% :)
Да же и меньше было.. была статься написанная другом Деминга, где он писал о том что в начале Деминг считал, что порядка 80% зависит от процессов, а 20% от персонала. А через несколько лет сам Деминг изменил этот процент уже на 95% и 5%. :)
Тут главное смысл ;)