Сразу хочу предупредить: в тексте ниже не идет речи о цифровой трансформации любого бизнеса вообще. Вероятно, есть пределы возможностей диджитализации. К примеру, небольшой фирме изготавливающей кухни на заказ или ИП занимающемуся частным извозом нет смысла полностью делать бизнес в цифре. Хотя имеются и такие кейсы.
Вообще, кажется, что цифровая трансформация — это больше про средний и крупный бизнес, а для малого она заключается лишь в выборе правильных продуктов хороших вендоров, решающих их конкретные задачи. Впрочем, многие со мной здесь не согласятся.
Хайп или неизбежность?
Впервые термин «цифровая трансформация» появился на страницах популярных бизнес-изданий примерно в 2015 году. Кризис уже вовсю бушевал, но в целом апокалипсиса не произошло. Средний и крупный бизнес не оказался на грани выживания. Еще были деньги на изменения. Незадолго до того о трансформации заговорили на различных около интернетовских и маркетинговых конференциях, как о чем-то неизбежном, что коснется всего бизнеса без исключения.
Сам термин, обозначающий ничто иное, как перевод бизнес-процессов в цифровой и преимущественно облачный формат, с соответствующей трансформацией продуктов и клиентского опыта, казался не конкретным. Но менеджмент в целом ощутил необходимость как-то двигаться в сторону освоения новых технологий – более продвинутых чем офисные приложения, почтовые сервисы и службы каталогов.
Вдохновленный акционер
Акционер некой компании, владелец типичного среднего бизнеса в сфере коммуникаций, как раз вернулся с крупной международной конференции переполненный идеями о цифровой трансформации. Он готов был идти на некоторые сравнительно большие расходы, чтобы сделать деятельность компании эффективнее и требовал порядка в том, что происходит. Это была хорошая идея, поскольку незадолго до того наш бизнес потерял почти $1 млн на внедрении системы управленческого учета, которая «не взлетела».
Он придумал прекрасную идею: объединил экспертов из нескольких департаментов в одну команду под условным названием «R&D Team». В ней не было руководителя, но был неформальный лидер – директор по IT. Каждые две недели мы собирались на рабочую группу с нашим акционером и придумывали, как будем трансформировать наше крупное рекламное агентство. Далее мы уже все вместе придумали регулярное мероприятие для рассмотрения новых инициатив: проектный комитет, который на основании подробного рассмотрения презентации проекта принимал решение о выделении бюджетов или отказе.
Много позже я обнаружил похожий порядок в МТС.
Работа закипела, но...
Это был 2015 год. У российского бизнеса оставалось еще 5 лет на то, чтобы измениться по своей инициативе, поскольку в 2020 году меняться заставила уже сама ситуация. Мы внедряли одну систему за другой. Полностью перешли на облачную офисную и почтовую инфраструктуру. Сколотили команду сильных разработчиков для создания нескольких продуктов в сфере медиазакупок ТВ и наружной рекламы. Однако, несмотря на примерно десяток успешно запущенных проектов, процесс трансформации, в общем и целом, через год-два застопорился, а накануне пандемии практически встал.
Акционер отошел от дел и больше не участвовал в заседаниях проектного комитета, а менеджмент не понимал зачем тратить деньги на то, что не принесет очевидных доходов в дальнейшем. Эффективность бизнеса все менее воспринималась руководством как доходная статья. В то же время старая бизнес-модель, основанная на медиадоходах и агентской комиссии с больших рекламных бюджетов, хорошо работала и несмотря на некоторые просадки приносила чистую прибыль в достаточных объемах для того, чтобы бизнес считался эффективным и без «трансформации».
В откровенных разговорах, мы на полном серьезе спорили, что будет дешевле на тот момент: купить/разработать систему за несколько миллионов рублей или нанять N ассистентов, которые выполнят ту же работу за свое жалование.
Команда R&D в конечном итоге распалась, заседания проектных комитетов прекратились, команда разработчиков и менеджеров, включая автора этих строк и IT-директора – разбежались за год-два.
Черный лебедь 2020 года: не до трансформации
Потом был черный лебедь-2020, необходимость аврального перехода не просто в облачную почту, но и на виртуальные рабочие места. А потом снизились рекламные бюджеты. Компании уже всерьез оказались в ситуации необходимости сокращения бюджета, с обнулением всех непроизводственных расходов и инициатив.
В общем уже совсем не до цифровизации процессов стало. Те, кто успел трансформировать свой бизнес только в 2020-м глобально начали пожинать плоды начатых 3-5 лет назад изменений, если они, конечно, были доведены до конца.
Февраль 2022: испытание для цифровых компаний
Потом наступил февраль 2022. Произошедшее можно охарактеризовать как второе за два года серьезное испытание для компаний, называвших себя цифровыми. Массовый отказ в приеме платежей, уход транснациональных IT-гигантов, аннулирование лицензий и контрактов, кибератаки и многие другие наложившиеся негативные факторы.
Конечно, это все отразилось самым негативным образом на неподготовленных к такому развитию событий компаниях. Оказалось, что цифровая трансформация должна быть проведена правильно, с учетом геополитических, санкционных и прочих рисков.
При этом нельзя однозначно утверждать, что нас совсем не предупреждали о возможности отключения западных решений. Предупреждали с 2014 года. Как и сейчас предупреждают о возможном уходе крупнейших IT-компаний и полных блокировках привычных операционных систем и мобильных устройств. И готовиться к этому надо прямо сейчас.
Что отличает хорошую digital-компанию от остальных
Понимание разницы между доведенной до конца и оборванной в нерешительности цифровой трансформации, приходит, когда сталкиваешься с компаниями прошедшими этот путь. В подобных компаниях тоже примерно в 2015-2016-х годах осознали, что «так дальше жить нельзя», необходимо что-то поменять. Что именно – не сразу стало понятно. В некоторых из них были запущены проектный и продуктовый комитеты. Причем первый был строго в контуре IT, а второй строго в контуре бизнеса.
В крупных корпорациях в рамках цифровой трансформации запускались десятки, сотни проектов, новые платформы и информационные системы. Нанимались разработчики, архитекторы, аналитики, либо переходили вследствие поглощений других компаний. Не все инициативы, на которые были потрачены миллионы рублей, стали успешными. Часть проектов вероятно пришлось закрыть с убытками. Однако, примерно через год-два отважные компании действительно обрели некоторые черты digital.
Когда я говорю о крутой digital-компании, я имею в виду совершенно конкретные вещи, которые восхищают всех, кто с ними соприкасается. Здесь я обозначу только самые базовые из них.
1. Виртуальное рабочее место
Прежде всего новый сотрудник получает в пользование полностью виртуальное рабочее место, которое доступно ему из любой точки мира и практически на любом железе. Это удивительно, когда ты приходишь в корпоративный коворкинг в другом городе и залогинившись на компьютере, который видишь впервые в жизни получаешь полностью готовое рабочее окружение, как будто ты только что вышел из-за своего компьютера в Москве налить чашечку кофе и вернулся за него в Санкт-Петербурге просто убрав заставку.
2. Все процессы цифровизированы
Все процессы, связанные практически с любой частью бизнеса в таких компаниях цифровизированы. Чем бы вы не занимались: продажи, цифровые продукты, маркетинг, HR, PR, финансы, закупки, обучение сотрудников, юридические вопросы, безопасность, съемки сериалов – практически для любой деятельности у вас обязательно есть своя информационная система, либо (в последнее время это тренд) – часть большой информационной системы, которая автоматизирует львиную долю ваших действий и сохраняет все данные.
В digital-компаниях подобный подход уже привычен и вошел корпоративную культуру. Мы знаем, что для того, чтобы выполнить тот или иной процесс, нужно зайти в ту или иную нашу систему, сделать определенные действия для достижения результата. Процесс согласования документов – полностью оцифрован. Никаких перекидываний электронными письмами. Есть четкий срок согласования рецензентами, ты сразу видишь кто тебе какие комментарии оставил по документу, отрабатываешь их и получаешь заветную «зеленую визу».
3. Ресурсы компании в корпоративном облаке
Для сотрудника dgital-компании абсолютно в порядке вещей при запуске нового проекта получить ресурсы в корпоративном облаке автоматически. Они выдаются на 3-6 месяцев. Если проект выстрелит – за счет защищенных на продуктовом комитете денег долг по ресурсам закрывается. Если не выстрелит, ресурсы возвращаются.
4. Наличие коммунальных сервисов
А еще есть коммунальные сервисы, которых несколько десятков от корпоративного таск-трекера и базы знаний до систем мониторинга серверов и BI. Абсолютно обыденная BigData с DataLake, со стандартами каталогизации и описания данных. Корпоративные стандарты разработки и архитектуры, стандарты надежности, платформы для связи множества сервисов между собой.
В общем, много всего хорошего сделано такими компаниями за прошедшие 6-7 лет.
Выводы
Сейчас мы воспринимаем digital как само собой разумеющееся. Это рутинный инструмент для жизни и бизнеса. Digital перестал быть фетишем менеджмента или высокой целью. Он стал реальностью нашей работы. Мы работаем с помощью digital и во многом внутри него. А быть не digital – это уже как-то странно.
Да, средний и крупный бизнес имеют колоссальные различия в плане доступных ресурсов. Крупные компании могут (или могли) себе позволить вливать любые, практически ничем не ограниченные средства в проекты, которые могут «не взлететь». Средний и малый бизнес всегда вынужден экономить. Но важно другое. Ставим ли мы фразу «быть digital» условием существования нашего бизнеса или воспринимаем цифровизацию как 5-7 лет назад, в качестве модного слова с конференций.
Процесс цифровой трансформации компании занимает в среднем 3-5 лет. В 2015 году у всех они были. У многих еще были ресурсы. Но далеко не все смогли правильно воспользоваться этими возможностями. Некоторые вообще ничего не делали, считая диджитализацию неким хайпом. Некоторые начали, но не завершили процесс оставшись практически при своем. Кто-то сумел выжать максимум из имевшегося в распоряжении времени и подошли к пандемии и нынешним событиям, решив все основные задачи digital-трансформации. Это очень хороший урок.
Вопросы, которые можно задать всем желающим изменить свой бизнес я вижу примерно такими:
- Принял ли высший менеджмент, а еще лучше – акционеры – цифровую трансформацию как стратегическую цель развития компании на ближайшие 3-5 лет?
- Удерживается ли компания эти 3-5 лет в рамках избранной стратегии или, пугаясь первых же неудач, поворачивает назад?
- Самое главное: верят ли менеджмент и акционеры в успех начатого ими дела?
Уверен, что после честных ответов на эти вопросы любой предприниматель или менеджер, читающий эти строки, приблизит успешную цифровую трансформацию своего бизнеса.
Читайте также:
Знаете, я уверен, что все кроме эмоций и смекалки хорошего продажника можно перевести в цифру. Сущности товаров и услуг, их предложение, сборка корзины, само оформление продажи, биллинг - не кажутся сложными для цифровизайии. Вопрос грамотной архитектуры и большого капекса. А вот за молчание в СЭД автоматически можно ставить неуд. После 3 неудов из согласующих можно и убрать. Проблема типичная, но тоже не блокер.
Если вы продаете жареные пирожки, то можно.
Если более сложный нишевый продукт, например систему глубокой очистки воды -- то не получится.
Даже если вы детально опишите продукт и все его конкурентные преимущества, снимите видео, запостите 100 фоточег в Инстаграм и запостите FAQ на 20 вопросов -- много идеальных для вас покупателей не купят потому что, они не хотят читать вашу писанину или смотреть видео с вами.
Они хотят позвонить или написать вам и получить ответы на свои вопросы из первых рук от живого человека. Людям нужно внимание. Они хотят почувствовать вашу эмоцию и уловить вашу экспертность.
С другой стороны, автоматизация продаж нагоняет много левых покупателей, издержки по которым могут быть настолько высоки, что вы потом будете сожалеть о том, что продали свой товар некоторым из них.
В личном контакте моя команда на раз таких идентифицирует и для них у меня нет предложнения. Спасибо, досвидания.
Если сложный инженерный продукт -- однозначно нет.
Лично я избегаю общения с тупыми ботами или автоответчиками. Я не покупаю у роботов ничего. Ну, может быть кроме пепси в вендинговом автомате.
Я покупаю только у живых людей, которые знают свой продукт и испытвают страсть к нему, которой готовы поделиться со мной.
Остальные идут лесом.
Мое внимание, мой рубль и меня как клиента надо заслужить. И за этот труд я отплачу тем, что порекомендую и приведу потом армию других покупателей. Ибо я активно продвигаю то, что ценю.
Это верно. Когда читаю про внедрение СЭД, то ловлю себя на мысли - неужели у всех всё нормально и только у нас так грубо и цинично игнорируют её возможности? Даже такую простейшую операцию, как уход в отпуск, при помощи компьютерных наук сделали чрезвычайно сложной и непонятной. Единственное что исключили из процесса - доставку заявления в офис. Раньше был курьер, а тепрь через СЭД. Но подписи, сканирование и прочее всё осталось.
Но есть и ещё одна сторона - частичная беременность. Например внедряют некую Jir'у...Задачки пишутся, время учитывается, но реальное управление проектом идёт в 333 мессенджерах. Плюс "голосом", а результаты митингов никому не доводятся. А мессенджер связан со вкусом или кругом общения самого главного автоматизатора.
отлично! Если билеты покупали, то ЭЭ оставался на приемлемом уровне и небыло никакого экономического основания что-то менять... тем более в условиях дефицита и заменить не на что было... иначе какой это дефицит..
Цитирую Вас:
"Елена Бреслав пишет:Этот чудесный самолет в плане ЭЭ давал 100 очков вперед самолетам более новых типов: .... Вот только пассажиры на нем летать уже тогда не хотели. Поэтому решался вопрос о том, на каких линиях на какой более новый тип его заменять."
Хотели, не хотели - это просто каприз, который в рассчете ЭЭ не участвует...
Николай, вы сейчас и в статье пишите о Цифровизации, но в названии статьи упомянули провал Цифровой Трансформации - разницу между ними как определяете?
Или это редактор. как часто бывает на этом ресурсе, название статьи придумал?
Давайте, почему нет. Вдруг это интересно и кому-то еще. Ответ будет длинным и скучным.
Замечательно. Всё по этому списку нужно детализировать.
Что там было записано в разделе целей, критериев успеха проекта и вообще Scope? С этим всё в порядке? На скольких уровнях организации это обсуждалось?
Идеально! Так не бывает, но ... Вам виднее.
Все это (и даже больше) было известно до начала проекта и должно было бы быть учтено в проектной документации и планах. Люди, естественно, как-то работали без новой системы.
Тут мои комментарии не нужны. Что было - то было.
Это относится к предпроектным работам и их промежуточным результатам. Обычно одного человека мало для подобных выводов, но с целями, критериями успеха и функционалом в проекте должен быть консенсус.
Схематично: сейчас мы вот здесь, это делаем - это не делаем, это вслед за тем, это с этим - параллельно. Тогда есть шансы при попутном ветре примерно за такие деньги примерно этими ресурсами и примерно в такие сроки получить примерно вот это. Делаем - Да/Нет? Ответ "Не знаю" не допускается.
В реальности всё сложнее, но всегда есть несколько обязательных вещей. Упомянутый Вами отв. человек тоже может быть неправ в любом месте.
Практически всё из перечисленного - дело техники, ничего особенного не вижу. Что-то из допущений обычно можно посмотреть и/или проверить заранее, внести коррективы и двигаться дальше.
Вы затронули много практических аспектов внедрения - и не только.
Общее пожелание: много думать и советоваться, делать то, что нужно, не срезая углы и без резких движений, хорошо понимая все особенности проекта. Держать руку на пульсе на всех этапах и в контрольных точках от предварительных изысканий до начала промышленной эксплуатации. Проверять, где можно. Всё выполнимо. Подвиги не нужны.
Из простого:
Цели внедрения должны включать новые качества и функционал, который просто не мог быть реализован в предыдущей жизни. Это неплохо стимулирует с точки зрения сначала повышения желания работы с новой системой, а затем - интенсивности и продуктивности.
Крайне важно: своевременное и поэтапное обучение сотрудников в песочнице и/или с демонстрационными примерами и кейсами до начала опытной эксплуатации. Цели внедрения должны быть понятны и не вызывать отторжения, а примеры вытекать из повседневной работы. Затраты тут небольшие, а результаты могут порадовать.
Project Risk Management - начиная с предварительных изысканий и вплоть (иногда - еще дольше) до промышленной эксплуатации. Мало ли что случится, но с этим нужно будет работать.
Очевидно, что внедряемая система должна быть хорошо спроектированной, максимально дружелюбной и удобной для подготовленного пользователя. Даже самые добросовестные сотрудники не будут заполнять все 99 обязательных (с точки зрения авторов) полей, чтобы перейти на следующий экран. Или, еще чаще, в системе будет накапливаться мусор, что быстро сделает её бесполезной. Массовый саботаж - совсем не редкость.
Управление изменениями в крупной компании обычно обсуждается в более широком контексте с точки зрения организации и может идти параллельно с планированием и выполнением проекта. Но круг вопросов гораздо шире и выходит далеко за рамки проекта.
К примеру, часто нужна полноценная ревизия существующих процессов, внутренних документов и регламентов, иногда - должностных обязанностей и трудовых соглашений, реже - организационной структуры. Цель - понимание во всех деталях, как компания работает сейчас, что и как именно изменится, как это отразится на сотрудниках, когда и какой и эффект можно ожидать, что, кому и в какой момент нужно сделать, чтобы внедрение и эксплуатация шли как можно более гладко.
Каким именно документам и т.п.? См. выше. Если мы серьезно относимся к планированию и проекту в целом, то шансы на успех достаточно высоки. Скажем, сильно выше среднего. Если, конечно, все действительно выполнили свою часть работы так, как это требовалось.
Никаких чудес. Наказать или уволить можно любого, но размазанная ответственность не обсуждается.
Кто у нас менеджер (директор ... название по вкусу) проекта? Успех проекта - его зона ответственности. У него есть все полномочия и прямой выход на спонсора проекта в сложных случаях. Сделал ли менеджер проекта всё, что было нужно на каждом и всех этапах? Очень многие (не все) проблемы относятся к решаемым, если их не запускать и вовремя лечить. Иначе самолеты бы не летали, а мы бы пользовались ручкой и бумагой в клетку (кстати, тоже неплохо работает) и не обсуждали бы тут внедрение BI.
Скажем, одна из главных причин провала проектов в IT - потеря коммуникаций. Проектный комитет, стоящий во главе орг. структуры проекта, видит такие проблемы заблаговременно и должен принять соответствующие меры. Процедуры эскалации при нарушении планов коммуникаций буквально творят чудеса, если о них не забывать, а менеджер проекта достаточно опытен, толстокож и настойчив.
===
Мой подход понятен?
Евгений, вы развернуто ответили, вы ушли немного в сторону технических аспектов.
В своем комментарии - я обозначил:
Пример приведен в упрощенной форме.
Как это учесть в проектной документации? в проектной документации учтен план внедрения и обучения сотрудников работе системой. На этапе предпроектки - все дружно сказали да, конечно, круто - будем пользоваться. Риски не использования кто определяет и как?
Конечно дело техники - система внедрена, но ей не пользуются.
Система - максимально дружелюбна (Qlick Sense (View)), все прекрасно работает, саботажа нет, заполнять ничего не нужно - мы про BI для пользователей (преднастройки осуществляет отдельный департмент).
Все таки мы сузили тему до конкретного проекта. Как действовать собственнику нужно было на ваш взгляд, до момента внедрения BI-системы?
Это основной/обязательный процесс перед запуском любой цифровизации/ЦТ.
В приведенном примере - система внедрена - но не используется в работе не из-за саботажа, а из-за фактора привычки и непонимания ценности и частично из-за отстутсвия цифровых навыков работы с системой.
Размазанная, имеется ввиду, что должен быть выделен один конкретный человек с которого итоговый спрос, а как там внутри не так важно.
Проект внедрения BI-системы прошел успешно: система функционирует, согласно заявленным требованиям. Большинство сотрудников не пользуются BI, те кто принимал работы пользуются BI.
Это относится к сложившейся культуре работы с информацией в компании.
Из вашего проектного опыта, каким образом решалась такая задача?
Это да, такая причина, как отсутств. или потеря комм или неверная коммун. - вообще основа провалов во всем.
Подход понятен, но мы немного про другое - проект внедрен, система работает, пользоваться не стали.
И вот исходя из приведенных мной опросов по провалам ЦТ, следует что сложившаяся "культура" в компании - является препятствием, также как и в приведенном мной примере. Система взлетела через 5 лет, но для этого потребовалось перестроить управление компанией.
Все так, проектные технологии и соблюдение всех этапов (вкл. оценку рисков) - сильно помогает снизить % неудач, но есть что-то, что описать не удастся и здесь нужны лидеры, как вообщем-то и при реализации проекта (бывают такие заказчики, что выкрутят все - но нужно уметь держать удар и парировать).
P.S. В одной ИТ-компании (в год более 1000 проектов) еженедельно проходят проектные (внутренние) онлайн-встречи, на которых отдельно разбирают провалы проектов и успешные внедрения. В большинстве случаев успешных внедрений - это отличная коммуникация с заказчиков, вторым аспектом - "граммотность" заказчика. Из неудач - чаще недопонимание/не совпадение ожиданий/факта.
Да нет конечно же! Не только "у вас" или "у них". Это совершенно обычное явление! Да, в каких-то организациях с этим лучше, даже очень хорошо. А где-то наличие СЭД просто отменило хождение по коридору с бумажкой в руке. В ряде организаций вообще всё "только через звонок" и с обязательной печатью "на бумаге". И не важно, что документооборот "электронный".
А это вообще самое смешное! Потому что Jir`у очень любят те самые интеграторы и разработчики ПО, которые всем же и продают ту самую автоматизацию. "Доктор исцели себя сам".
Причин на то много - пресловутая "цифровая грамотность" работников, недоверие электронике, юридическая незначимость электронных документов/сообщений, низкая квалификация руководителей, корпоративная культура и прочее.
Наконец просто коммуникативные особенности! Представьте себе человека, который за день ни с кем из коллег по работе не разговаривает - только СЭД и Jira! Только постановка задач, контроль, общение комментариями, нажатие "согласовано/отказано"? Это какой-то интроверт-отшельник получается!
В общем "всё автоматизировано" это, на настоящем этапе развития человеческого общества - миф! Когда в него верят всякие там "не связанные с отраслью" - пожалуйста! Но ИТ-шникам, как я считаю, подобное непростительно!
Абсолютно напрасно уверены:
1. Вы можете перевести в цифру процессы внутри организации, но останутся коммуникации между сотрудниками. Эти, как их там, человеческие.
2. А ещё есть внешние для организации участники процессов - клиенты, бывшие и будущие сотрудники, госорганы. Им ваша автоматизация не интересна и вы будете вынуждены с ними общаться как они хотят, а не как вы.
Я натыкался на исследование, что порядка 30% населения ЕС, по результатам КОВИД-удалёнки, продемонстрировали нежелание использовать каналы продаж "без личного общения с продавцом". Ссылок у меня нет, но смысл, думаю, понятен. Даже 10 - 15% в данном случае это много.
3. Вы говорите об организациях, чьи процессы сосредоточены "внутри". А есть организации, чьи процессы смешаны с клиентами, вовлекают клиентов в процесс несколько раз. Например общественный транспорт, здарвоохранение, образование.
Там клиент может стартовать группу процессов и появляться в середине процесса ещё несколько раз. А исполнитель может не иметь никакой связи с сервером и постоянно принимать решения по процессу лично, с использованием бумаги.
Это вам не бухгалтерию автоматизировать - счёт загрузили, кнопку нажали и на оплату через СЭД.
Охохох... Ну не нужно такого говорить, а? Подобные методы решения, они эээ, не рабочие совсем и никак. Уберёте один раз человека, который должен нести ответственность - понесёте её сами. Это я кратко, могу подробно на пару листов с примерами.
Да, я понял. Детали Вы не приводите. Даже размер компании и количество рабочих мест.
Посмотрите еще раз на цели внедрения и критерии успеха проекта. Что там было сказано (я этого, естественно, не знаю)?
Проектная документация готовится по исходным данным, получаемым от заказчика. Каждый документ - в своё время и по своим данным в соответствии с планом подготовки документации, включая согласование и утверждение.
Всё, что имеет отношение к делу, начиная с информации и требований заказчика, должно быть так или иначе учтено.
Это тот же вопрос о целях проекта - ничего нового.. Но вопрос сложный.
Что и как именно должно было измениться в процессах после внедрения системы?
Зачем внедрять систему, если сотрудники всё (!) могут делать без нее более удобными (для них), простыми и другими существующими инструментами и способами? Всё работает без нее и даёт приемлемые результаты.
Риски для начала пишутся в столбик, регулярно обсуждаются, дальше с ними идет обычная работа. Указанный Вами - один из. В том же списке.
Пока ходим по кругу.
Зачем вообще была нужна эта замечательная, дружелюбная и удобная система - в практическом плане?
Change Management работает с дельтой между существующим состоянием организации и новым / планируемым и старается сделать этот переход как можно более мягким и безболезненным.
Анализ различий должен быть честным и профессиональным, что бы собственник изначально не предполагал. Иногда выводы могут быть для него неожиданными - например, резкий рост каких-то затрат.
Чем меньше эта дельта, тем меньше аргументов в пользу крупномасштабных проектов. Похоже, что такое случилось в Вашем упрощенном примере, но без деталей проекта это нет смысла обсуждать.
Вы видели результаты этих работ? Что там было? Судя по Вашим словам, кое-что важное упустили или пропустили.
Привычки меняются в процессе работы и никак иначе. Когда-то траектории ракет считали на логарифмической линейке, с таблицами и табуляторами, потом постепенно перестали.
Отсутствие навыков и практики понятно, предсказуемо и закрывается обучением в плановом порядке. Начинать можно ближе к опытной эксплуатации. Если нужно - дополнительным обучением со скорректированными целями, программой и примерами. Плавали, знаем - это неплохо работает.
Сомневаюсь - см. выше о целях и критериях успеха. Тут нельзя прыгать через ступеньку. Дальше мне нужны детали.
Такое бывает и зависит от организации, начиная с отрасли и масштабов.
Напишите мне в почту вопросы, обсудим, если я знаю ответы. Вряд ли это соответствует теме, формату и пр. данной дискуссии на этом ресурсе. Можно открыть другую.
Я о том же - помогает сильно. Всё перечисленное выше обязательно, но, увы, далеко не всегда выполняется. Как мытьё рук перед едой.
Вы правы - бывает всякое. Опытный менеджер проекта должен быть лидером, другие в крупных проектах не выживают. См. также выше о толстокожести.
Можно добавить пару слов о работе в условиях постоянного стресса и других необходимых качествах, но это очевидно для всех наших читателей.
Это совершенно правильно и является стандартом практически для всех организаций, где есть PMO или что-то функционально похожее.
Post-mortem analysis крайне полезен всем участникам и не только при обсуждении проектов. Верно и для аварий, серьезных инцидентов и пр..
Всё это так. Для меня вторая по важности причина провала проекта - проблема Scope.
Добавлю ,что в части разработки ПО Agile PM во всех вариантах появился далеко не просто так, это серьезный вопрос на уровне отрасли. Его авторы и первые идеологи - PM очень высокого уровня. В других областях это иначе.