Кому сложнее всего перейти на гибкую организацию бизнес процессов

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

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

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

Основной проблемой в рамках пандемии для обоих бизнесов стало снижение посещаемости до абсолютного нуля.

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

Простые нотации описания бизнес-процессов, которые читают и используют сотрудники

Из коворкинга в сервисные офисы

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

Лучшим решением стала адаптация бизнес-модели в сторону формата b2b и поиск возможности реализовать сразу 80-100% площади. Этой стратегии идеально соответствовала модель сервисного офиса, когда арендатор — это крупная компания, а мы — оператор пространства.

Узнайте, как ускорить работу сайта на 20% и увелить число пользователей в 4 раза с помощью облачного провайдера. Подробнее по ссылке

При смене модели с b2c на b2b важно просчитывать следующие риски:

Разницу требований

Стоимость привлечения клиентов

Гибкость пространства

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

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

Приняв решение о смене модели, мы начали переговоры и вскоре заключили партнерство с Apollax Group, в конце 2020 года переформатировали 64 мини-офиса на Рябовской мануфактуре в большое офисное пространство Apollax Space. Инвестиции в проект составили 100 миллионов рублей.

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

Отель «Симонов парк»: когда гости стали арендаторами

На время карантина мы законсервировали отель и продержали его в таком состоянии до июня, до снятия «двухнедельного карантина».

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

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

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

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

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

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

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

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

Тяжелее всего пандемию пережил ресторан в отеле. Он потерял 30-40% своего оборота и вышел из кризиса с 10%-м падением выручки по сравнению с прошлым годом. Однако по всем остальным параметрам нам с командой отеля удалось практически безболезненно пройти через кризис.

Как добавить гибкости бизнес-модели?

Неважно, в каком рынке работает компания — всегда можно заложить пространство для маневра. Именно гибкая адаптивная бизнес-модель дает возможность быстро вносить изменения.

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

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

Источник: rb.ru

Agile не на словах, а в головах

В каких сферах применим Agile и когда можно считать, что методика успешно внедрена?

корреспондент
корреспондент

Усложнение бизнес-процессов, вызванное влиянием информационных технологий, заставляет компании меняться. Место проектного подхода и сложных иерархических структур занимают гибкие процессы управления и формирования «творческих коллективов». Однако внедрение Agile-методов может не дать ожидаемого результата. О подводных камнях процесса трансформации организационной структуры рассказал управляющий партнер компании «Ионов и Партнеры» Алексей Ионов.

1 2 04/10/2018

Переход на Agile: внедрять нельзя откладывать

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

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

Внедряя Agile в организациях, мы специализируемся на подходе Scaled Agile Framework® (SAFe®). Компании, перешедшие на SAFe, декларируют в среднем рост мотивации сотрудников на 10–50%, повышение производительности на 20–50%, снижение количества дефектов на 25–75% и, самое важное, ускорение доставки продукта до рынка на 30–75%

Алексей Ионов
управляющий партнер компании «Ионов и Партнеры»

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

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

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

Трансформация команды

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

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

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

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

Справка

В Agile-организации могут присутствовать следующие роли:

Product Manager, или менеджер продукта;
Product Owner, или владелец продукта;
Scrum Master , или сервис-лидер команд;

Agile coach/Change agent, или лидер-коуч изменений;
Competency/community leader, или лидер компетенции/сообщества;
Development Team member, или член команды разработки;
Business Owner/Business Partner/Stakeholder, или представитель бизнеса зарабатывающего подразделения;
и т.д.

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

Поэтому важно, чтобы «центр» пересмотрел взгляды на систему управления.

Менеджеры должны стать лидерами, а не начальниками

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

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

«Грабли» Agile-трансформации

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

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

Такой способ организации работы в корне противоречит Agile, так как по сути это возвращение к обычной командной системе.

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

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

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

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

Этапы Agile-трансформации

Переход к практике гибкой разработки не одномоментный процесс, поскольку необходимо подготовить специалистов. Как правило, на первом этапе формируются и обучаются 3–7 команд по 6–9 человек каждая. По опыту многих компаний, это оптимальное количество для старта, хотя известны истории одновременного обучения и запуска команд общей численностью около 200 человек. В любом случае, для этого требуется около одного-двух месяцев.

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

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

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

Алексей Ионов

Затраты vs результаты

Внедрение Agile – недешевая процедура. Стоимость запуска упомянутых 3–7 команд обходится в несколько миллионов рублей и более. Поскольку речь идет о глубоком и серьезном процессе перестройки всей организации, рассчитывать на бюджетный подход «прочитай книжку-послушай коучей» не приходится.

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

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

В конечном итоге внедрение Agile позволяет решать ключевые задачи бизнеса – увеличение прибыли и рост доли компании на рынке.

Нравится: 2 Была ли статья полезна? Да Нет

Источник: kachestvo.pro

Гибкость бизнес-процессов – ключ к успеху компаний

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

687 просмотров

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

СКАУТИНГ СТАРТАПОВ. КЕЙС ЧТПЗ

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

На практике именно 20-30 % от общего числа заявленных проектов приходятся именно на иностранные стартапы.

Финальный этап скаутинга в рамках совместного акселератора GenerationS и ЧТПЗ пришелся как раз на период экономического спада (март 2020 г.), что влекло за собой определенные сложности в рамках проработки заявок зарубежных проектов. С их стороны наблюдалась значительная озадаченность и неопределенность в вопросе потенциального тестирования своей технологии в России. Был отмечен фокус на сохранение своего бизнеса, нежели интерес на участие в новых инициативах. В результате был разработан формат индивидуального подхода к каждому стартапу, где необходимо было с каждым заявителем лично проработать заявку, рассказать обо всех плюсах участия в программе, о том, какие возможности она дает – немного сместить фокус в сторону потенциально перспективных возможностей. Такой грамотный и адаптированный под новые реалии подход помог обеспечить качество всех поданных иностранных заявок на высоком уровне, что в работе любого акселератора является ключевым критерием отбора.

Запуская собственный акселератор, мы ставили задачу привлечь не менее 150 проектов с долей иностранных стартапов 50 %. Реализация программы выпала на сложное время: пандемия, экономический спад, общая неопределенность. В Группе ЧТПЗ понимают, что любое состояние неопределенности влечет за собой риск недостижения поставленных целей, но также мы осознаем, что любой кризис – время новых возможностей, в первую очередь для развития бизнеса, поэтому в такой ситуации как никогда важна грамотная работа специалистов.

В условиях сложной эпидемиологической обстановки работа экспертов ЧТПЗ и GenerationS была переформатирована и быстро встала на новые рельсы: команды перешли в онлайн формат, скаутинг стартапов продолжился через телекоммуникационные каналы и сети. Быстрая реакция на изменения и слаженная работа специалистов принесли свои плоды: в акселератор заявили 300 инноваций, из которых 109 иностранных, притом релевантность направлениям отбора составила более 65%.

Мария Ильина, Руководитель корпоративного акселератора ЧТПЗ
ПИТЧ СЕССИИ. КЕЙС ЧТПЗ

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

Данная модель питч-сессии по своей эффективности продемонстрировала уровень ничуть не ниже, чем очная сессия.

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

Для Группы ЧТПЗ формат дистанционного общения привычен. Наша компания работает в трех регионах присутствия, и активное использование удаленных каналов бизнес-коммуникаций — неотъемлемая часть эффективности операционного и управленческого взаимодействия.

Мы ведем переговоры дистанционно уже более 5 лет, поэтому все встречи со стартапами в режиме вебинаров прошли легко и продуктивно.

Сейчас же перед нами стоит более амбициозная задача по выбору самых перспективных из предложенных решений для дальнейшего запуска “пилотов” на предприятиях Группы ЧТПЗ. В это непростое время реализовать подобную инициативу — вот настоящий вызов для команды акселератора и стартапов!

Антон Гизатуллин, Начальник управления новых видов продукции Группы ЧТПЗ
ЗАПУСК ПИЛОТОВ. КЕЙС ГТЛК

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

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

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

Как в несколько шагов эффективно перестроить работу над пилотными проектами?

1. Сделать расширенную дорожную карту, отметив точки, которые можно формировать удаленно. Например, в акселераторе ПАО «ГТЛК» есть серьезный блок, связанный с документами, которые формализуют работу проекта:

Соглашение о неразглашении (NDA) — необходимо для дальнейшего сотрудничества и формирования взаимоотношений во время и после акселератора.
Паспорт проекта — документ, в котором отражены основные условия пилотного проекта и результаты переговоров с подразделениями ПАО «ГТЛК» и компаниями-партнерами, включая ключевые показатели эффективности.
Смета пилотного проекта с четким описанием затрат и получаемых услуг.
Договор, в который включаются паспорт и смета для предоставления финансирования на пилотный проект. Данную работу можно реализовывать в акселераторе удаленно.

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

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

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

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

УДАЛЕННАЯ РАБОТА СОТРУДНИКОВ. КЕЙС PEPSICO

Российские работодатели перевели большинство сотрудников на удаленную работу, в связи с чем появились новые аспекты нашей ежедневной жизни. Например, встречи и конференции проходят с использованием таких инструментов, как Zoom, Webex, Skype и др. Чаще стали использоваться Microsoft Teams или Google Docs. Можно с уверенностью сказать, что к решению технических вопросов работодатели оказались готовы. Но не менее важным фактором оказалось эмоциональное состояние сотрудников.

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

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

В PepsiCo разработали ряд правил, которые помогут управлять своим временем и эффективнее работать удаленно:

Стандартный рабочий день большинства сотрудников с 9:00 до 18:00, но встречи рекомендуется назначать только с 9:00 до 17:00, обязательно предусмотрев время для обеда. При этом сотрудники могут работать по гибкому рабочему графику по договоренности с руководителем.
Бронировать столько времени, сколько действительно нужно, а не использовать стандартные промежутки в Outlook в 30, 60 или 90 минут. Например, можно назначать короткие 10-минутные встречи.
Приглашать только тех, кто действительно должен быть на встрече. Если вы пригласите шесть участников вместо четырех, продолжительность увеличится в среднем на 50 %.
Оставлять небольшие перерывы между встречами: назначать встречи на 25 минут вместе 30 или на 50 минут вместо 60.
В эти перерывы каждый человек не только сможет выпить Pepsi или «Чудо», но и подключиться к следующей встрече и закончить ее вовремя. Очень важно относиться с уважением ко времени коллег.
Мы призываем каждого оставлять хотя бы час в день на планирование и обдумывание текущих задач. Это несомненно принесет пользу и поможет спланировать свои дела.
Вечер пятницы предназначен для виртуальных командных вечеринок. И никаких деловых встреч после 16:00, кроме экстренных!
Придерживаться правила не назначать встречи и звонки коллегам вечерами и на выходных, если только ситуация не чрезвычайная.

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

Источник: vc.ru

Гибкость и надежность

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

Гибкость и надежность

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

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

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

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

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

Конфликт: гибкость против надежности

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

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

Описание конфликта

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы должны «находить новых и поддерживать существующих клиентов» (B), ПОСКОЛЬКУ (A-B):

«В нашем бизнесе успех означает, что мы достигаем роста прибыли» и/или
«Новый бизнес — жизненная основа нашей компании».

• Чтобы «находить новых и поддерживать существующих клиентов» (B), мы должны «немедленно реагировать на клиентские запросы» (D), ПОСКОЛЬКУ (B-D):

«Срочные запросы не редки».
«Клиенты работают с поставщикам, которые реагируют быстро».
«Задержки, вызванные реакцией на срочные запросы, не подвергают опасности существующий бизнес».
«Клиенты привыкли к задержкам».
«Заканчивать проекты позже (или не в полном объеме) — установившаяся практика в нашей отрасли».

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы «не должны подвергать опасности наши взаимоотношения с существующими клиентами» (C), ПОСКОЛЬКУ (A-C):

«У клиентов хорошая память»;
«Клиенты «наказывают» нас за невыполнение сроков прекращением сотрудничества».

• Чтобы «не подвергать опасности взаимоотношения с существующими клиентами» (C), мы «не должны немедленно реагировать на клиентские запросы» (D’), ПОСКОЛЬКУ (C-D`):

«Немедленная реакция задерживает другие активные проекты».
«Немедленная реакция приводит к многозадачности».
«Многозадачность приводит к потере мощностей».
«Потеря мощностей вызывает еще большие задержки».

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

Некоторые компании «создали» 50-100% защитные мощности (с существующими ресурсами) в своих проектных организациях и используют эти мощности, чтобы реагировать быстрее и производить больше.

Конфликт: гибкость против эффективности

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

Описание конфликта

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы должны «эффективно использовать ресурсы» (C), ПОСКОЛЬКУ (A-C):

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

• Чтобы «эффективно использовать ресурсы» (C), мы «не должны допускать вредную многозадачность» (D’), ПОСКОЛЬКУ (C-D`):

«Многозадачность уменьшает наши мощности на 25% и более».
«Многозадачность задерживает проекты на 25% и более».
«Потерянные мощности нарушают гибкость и надежность».

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

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

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

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

Критическая цепь рекомендует минимизировать многозадачность (устранить «плохую» многозадачность, если быть точным), но явно утверждает, что «ХОРОШАЯ» многозадачность допустима и имеет право на жизнь.

Конфликт: внедрять ли «сделанные на скорую руку» решения или нет

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

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

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

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

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

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

Описание конфликта

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы «не должны подвергать опасности сроки завершения наших проектов» (B), ПОСКОЛЬКУ (A-B):

«Своевременное завершение важно для лояльности клиентов».
«Немедленная быстрая реакция важна для поддержания или развития бизнеса».

• Чтобы «не подвергать опасности сроки завершения наших проектов» (B), мы «должны принимать решения на скорую руку» (D), ПОСКОЛЬКУ (B-D):

«Часто у нас недостаточно времени, чтобы принять качественное решение».
«Мы должны немедленно реагировать на срочные клиентские запросы».
«Ресурсы проекта оцениваются с позиции их гибкости: способности быстро отреагировать и вовремя завершить проект».
«Недостатки решения на скорую руку могут быть исправлены позже».

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы «должны гарантировать качество продукта» (C), ПОСКОЛЬКУ (A-C):

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

• Чтобы «гарантировать качество продукта» (C), мы «не должны принимать решения на скорую руку» (D), ПОСКОЛЬКУ (B-D):

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

Критическая цепь

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

Путь вперед

Высшее руководство должно понять, что в то время как Критическая цепь ограничивает многозадачность в целом, она не отвергает «хорошую» многозадачность.
Компания и клиент вместе выполняют анализ ситуации, в которой находится клиент, и разрабатывают концепцию решения. Необходимые условия, которым должно удовлетворять решение:
— гибкость;
— надежность;
— качество продукта (никаких решений на скорую руку);
— наличие мощностей, которые позволят обеспечить первые три приоритета и сохранить возможность для увеличения количества проектов — без общепринятых компромиссов.
Концепция представляется руководству проектной организации вместе с проектным предложением. Оно должно быть оформлено в виде не более чем 2-часовой презентации.
Проектное предложение представляется высшему руководству для одобрения.
Внедрение подхода — значительные результаты можно ожидать в течение 6-9 месяцев.

Книга в подарок

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

Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Источник: tocpeople.com

7 препятствий для внедрения гибких методологий в больших организациях

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

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

Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.

Препятствие #1: Наивный менеджмент ресурсов

В Руководстве PMBOK написано:

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

В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему:

«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»

Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».

Когда работа представляет собой разработку нового продукта, соответствующие ресурсы неосязаемы: понимание задачи, обучение, межличностное общение и инновации. Scrum-команды пытаются максимизировать их, создавая состояния индивидуального и группового «потока». Как утверждает психолог Mihaly Csikszentmihalyi: «[в потоке] вы полностью погружены в задачу, и вы используете все свои навыки на предельном уровне».

Члены Команды Разработки (Development Team) Scrum интенсивно взаимодействуют друг с другом, чтобы создавать продукты в соответствии с целями, которые они постоянно обсуждают с Владельцем Продукта (Product Owner). Владелец Продукта отвечает за принятие бизнес-решений в команде.

Результаты работы демонстрируются в конце каждого Спринта (Sprint) фиксированной длительности (например, каждые две недели). Во время Спринта члены команды развивают заинтересованность в общих целях и учатся управлять друг-другом для их достижения. Даже при идеальных условиях (в том числе, говоря о помещении, где работает команда) команде требуется принять участие в нескольких спринтах, чтобы достичь успеха, и около года, чтобы реализовать свой потенциал полностью. Широко известно описание этого органического процесса — «формирование, штурм, нормирование, выполнение» модели Брюса Такмана. (Bruce Tuckman, “forming, storming, norming, performing”).

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

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

Препятствие #2: Команды, организованные по функциональной принадлежности

Scrum‐команды это кроссфункциональные команды, которые стараются создать тщательно протестированный инкремент продукта каждый спринт, постепенно наращивая функциональность. Самая популярная книга по Scrum использует фразу “потенциально “Готового” к выпуску Инкремента продукта” (“potentially shippable product increment”) 18 раз. Несмотря на это, я встречаю людей, которые утверждают, что «практикуют Scrum», используя при этом «аналитические спринты» или «спринты проектирования» в начале проекта, откладывая интеграцию и тестирование на потом, и привлекая разные команды для выполнения каждой части работы. Привычки, приобретённые из Водопадной Модели Управления Проектами, скрывают риски до тех пор, пока не становится слишком поздно что-то делать.

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

Препятствие #3: Команды, организованные по архитектурно-компонентной принадлежности

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

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

Противоположностью Компонентной Команды является Функциональная Команда, ориентированная на разработку новых возможностей продукта (feature team). Функциональная Команда охватывает как компоненты, так и дисциплины, и, таким образом, способна реализовывать функциональные задачи для бизнеса в тонких, полностью протестированных «вертикальных срезах» продукта. Такой подход призван заменить концепции прошлого века, основываясь на концепциях автономности команд, самоорганизованности и ответственности. Бэклог продукта Функциональных Команд основан на нуждах бизнеса, а не на зависимостях от технологий. Если вы до сих пор используете Диаграммы Гантта, скорее всего у вас пока не организованы Функциональные Команды.

Создание Функциональных Команд связано с затратами: разработчики будут должны освоить новые навыки, что замедлит их в начале. К счастью, большинство разработчиков любят осваивать новые навыки. Методы, такие как назначение технического «хранителя компонент» (“component guardian”) для каждой области могут помочь защитить архитектурную целостность, поскольку команды учатся. Как и при любой масштабной разработке, непрерывная интеграция (автоматические тесты, выполняемые гораздо чаще, чем один раз в день) имеет решающее значение для предотвращения необнаруженных дефектов общей работоспособности продукта.

После того, как организация научится управлять Функциональными Командами, следующим шагом может быть — создание Функциональных Команд Общего Назначения (general purpose feature teams) с минимальными зависимостями от функциональных областей. Этот процесс может потребовать годы непрерывного обучения внутри организации.

Препятствие #4: Отвлечение внимания

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

Традиционные методы управления, которые усиливают специализацию, только усугубят проблему. Работу следует давать Scrum-команде во время встречи для Планирования Спринта (Sprint Planning Meeting). Когда менеджер не берет это во внимание, назначая задачи на конкретных исполнителей, у специалистов не оказывается возможности наставлять и обучать других важным навыкам.

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

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

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

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

Препятствие #5: Нежелание непрерывно пересматривать, приоритезировать и детализировать Бэклог Продукта

При разработке продукта, скорость обнаружения новых задач, которые необходимо сделать, обычно опережает скорость самой разработки. Чтобы справляться с этим, Владелец Продукта должен проводить Уточняющие Встречи (Refinement Meetings) для пересмотра, приоретизации и уточнения задач в Бэклоге Продукта каждый Спринт. Когда в Бэклоге появляются слишком большие задачи («epics»), необходимо находить их ключевые аспекты и делить их на маленькие подзадачи (обычно называемые «User Stories»). Владелец Продукта управляет объемом работ, решая, какие задачи войдут в Релиз, с учетом данных о скорости разработки и объеме работ, выполняемом в течение Спринта.

Препятствие #6: «Технический Долг»

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

В идеале, регрессионные тесты можно автоматизировать с помощью того же языка программирования, что используется при разработке продукта, без использования проприетарных инструментов, которые только усиливают зависимость от специфичных знаний. Навыки, такие как Test Driven Development (TDD), доказали свою ценность в 20-м веке. В 21-м веке от любого разработчика ожидается навыки владение гибкими методологиями. И команды, которые этими навыками еще не обладают, должны пытаться работать с «вертикальными срезами задач», пока они не научатся.

Препятствие #7: Нежелание меняться

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

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

Управление разработкой
Управление проектами
Agile
Управление продуктом
Управление персоналом

Источник: habr.com

Источник

Предложите, как улучшить StudyLib

(Для жалоб на нарушения авторских прав, используйте

другую форму
)

Ваш е-мэйл

Заполните, если хотите получить ответ

Оцените наш проект

Источник

СКАУТИНГ СТАРТАПОВ. КЕЙС ЧТПЗ

На практике именно 20-30 % от общего числа заявленных проектов приходятся именно на иностранные стартапы.

Запуская собственный акселератор, мы ставили задачу привлечь не менее 150 проектов с долей иностранных стартапов 50 %. Реализация программы выпала на сложное время: пандемия, экономический спад, общая неопределенность. В Группе ЧТПЗ понимают, что любое состояние неопределенности влечет за собой риск недостижения поставленных целей, но также мы осознаем, что любой кризис – время новых возможностей, в первую очередь для развития бизнеса, поэтому в такой ситуации как никогда важна грамотная работа специалистов.

В условиях сложной эпидемиологической обстановки работа экспертов ЧТПЗ и GenerationS была переформатирована и быстро встала на новые рельсы: команды перешли в онлайн формат, скаутинг стартапов продолжился через телекоммуникационные каналы и сети. Быстрая реакция на изменения и слаженная работа специалистов принесли свои плоды: в акселератор заявили 300 инноваций, из которых 109 иностранных, притом релевантность направлениям отбора составила более 65%.

Мария Ильина, Руководитель корпоративного акселератора ЧТПЗ

ПИТЧ СЕССИИ. КЕЙС ЧТПЗ

Данная модель питч-сессии по своей эффективности продемонстрировала уровень ничуть не ниже, чем очная сессия.

Для Группы ЧТПЗ формат дистанционного общения привычен. Наша компания работает в трех регионах присутствия, и активное использование удаленных каналов бизнес-коммуникаций — неотъемлемая часть эффективности операционного и управленческого взаимодействия.

Мы ведем переговоры дистанционно уже более 5 лет, поэтому все встречи со стартапами в режиме вебинаров прошли легко и продуктивно.

Сейчас же перед нами стоит более амбициозная задача по выбору самых перспективных из предложенных решений для дальнейшего запуска “пилотов” на предприятиях Группы ЧТПЗ. В это непростое время реализовать подобную инициативу — вот настоящий вызов для команды акселератора и стартапов!

Антон Гизатуллин, Начальник управления новых видов продукции Группы ЧТПЗ

ЗАПУСК ПИЛОТОВ. КЕЙС ГТЛК

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

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

Как в несколько шагов эффективно перестроить работу над пилотными проектами?

1. Сделать расширенную дорожную карту, отметив точки, которые можно формировать удаленно. Например, в акселераторе ПАО «ГТЛК» есть серьезный блок, связанный с документами, которые формализуют работу проекта:

Соглашение о неразглашении (NDA) — необходимо для дальнейшего сотрудничества и формирования взаимоотношений во время и после акселератора.
Паспорт проекта — документ, в котором отражены основные условия пилотного проекта и результаты переговоров с подразделениями ПАО «ГТЛК» и компаниями-партнерами, включая ключевые показатели эффективности.
Смета пилотного проекта с четким описанием затрат и получаемых услуг.
Договор, в который включаются паспорт и смета для предоставления финансирования на пилотный проект. Данную работу можно реализовывать в акселераторе удаленно.

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

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

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

УДАЛЕННАЯ РАБОТА СОТРУДНИКОВ. КЕЙС PEPSICO

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

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

В PepsiCo разработали ряд правил, которые помогут управлять своим временем и эффективнее работать удаленно:

Стандартный рабочий день большинства сотрудников с 9:00 до 18:00, но встречи рекомендуется назначать только с 9:00 до 17:00, обязательно предусмотрев время для обеда. При этом сотрудники могут работать по гибкому рабочему графику по договоренности с руководителем.
Бронировать столько времени, сколько действительно нужно, а не использовать стандартные промежутки в Outlook в 30, 60 или 90 минут. Например, можно назначать короткие 10-минутные встречи.
Приглашать только тех, кто действительно должен быть на встрече. Если вы пригласите шесть участников вместо четырех, продолжительность увеличится в среднем на 50 %.
Оставлять небольшие перерывы между встречами: назначать встречи на 25 минут вместе 30 или на 50 минут вместо 60.
В эти перерывы каждый человек не только сможет выпить Pepsi или «Чудо», но и подключиться к следующей встрече и закончить ее вовремя. Очень важно относиться с уважением ко времени коллег.
Мы призываем каждого оставлять хотя бы час в день на планирование и обдумывание текущих задач. Это несомненно принесет пользу и поможет спланировать свои дела.
Вечер пятницы предназначен для виртуальных командных вечеринок. И никаких деловых встреч после 16:00, кроме экстренных!
Придерживаться правила не назначать встречи и звонки коллегам вечерами и на выходных, если только ситуация не чрезвычайная.

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

Александра Сухарева, Руководитель TechLab, PepsiCo Россия

Источник

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

Бизнесу выгодна повторяемость деятельности, включая ее результат. Повторяемая деятельность — это деятельность, которая может воспроизводиться по одному и тому же шаблону. Например, деятельность «Заключение договора» или даже более глобальная — «Строительство дома». Повторяемость дает возможность «один раз» детально продумать деятельность, подготовить необходимые для нее средства (оборудование, компьютеры, ИТ-системы, здания и т. п.), людей, скомпоновать их в «жесткую машину деятельности», а потом многократно ее использовать. Это дает серьезную экономию, т. к. затраты на проектирование деятельности и подготовку средств осуществляются один раз, а сама деятельность — многократно. И чем больше ее повторений, тем значительнее эффект экономии. Поэтому бизнесу однозначно выгодна повторяемость деятельности. Он ее «хочет» и он к ней «стремится».

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

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

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

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

Универсальный трактор

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

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

2. Оперативная сборка «машины деятельности»

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

— Степан! У гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!

Кинофильм «Формула любви»

Реакция на такие запросы требует от организации как бы «минипроектов», в которых могут участвовать один или несколько сотрудников. Если проанализировать виды деятельности, которые возникают в таком минипроекте, то неизбежно среди них будет «придумывание» технологии деятельности, поиск необходимых средств, инструктаж участников «минипроекта» — словом, вся та классическая деятельность, которую можно наблюдать и в проекте, и при создании «жесткой машины деятельности». При этом совершенно неважно: будут ли фиксироваться разработанные решения «на бумаге» или «умрут» в головах участников вместе с окончанием минипроекта; один участник разрабатывает технологию или это происходит коллективно, кто является главным ответственным за выработку технологии и сборку «машины деятельности» — руководитель или сотрудник. Главное — что данные виды «инженерной» деятельности реально осуществляются.

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

3. Быстрая перестройка компании

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

Перестройка может быть вызвана, например:

Необходимостью другого результата деятельности (новая продуктовая линейка);
Появлением новых средств деятельности (знаний, технологий, оборудования), которые дают существенный экономический выигрыш;
Требованиями государства (например, введением ЕГАИС для контроля оборота алкоголя).

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

С того момента, когда установлена необходимость перестройки компании, начинается отсчет времени. Изменение даже большой компании не должно представлять проблему, если она УЖЕ обладает грамотно спроектированной архитектурой. Например, с использованием системно-инженерного принципа модульности, когда связи между модулями минимизируются, а внутри компоненты модулей могут быть связаны сильно. Реализацией этого принципа является и подход, пропагандируемый Тимуром Кадыевым — «Один процесс — одно подразделение», означающий, что один процесс целиком должен находиться в границах одного подразделения. За счет минимизации связей между подразделениями появляется возможность менять их достаточно независимо друг от друга. Но это в теории. На практике компании с такой архитектурой встречаются редко. Плюс, на возможность быстро спроектировать и провести изменения накладывают отпечаток межличностные отношения руководителей, которые не всегда способны договориться друг с другом.

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

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

Заключение

В статье рассмотрено три вида гибкости компании:

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

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

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

Опубликовано по материалам:
http://e-xecutive.ru/management/practices/1986310-chto-takoe-gibkaya-kompaniya

Февраль 2017 г.

Как понять, что компания готова участвовать в описании и оптимизации процессов?

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

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

Константин Зусманович, управляющий партнер Financial Mechanics:

Компания, по большому счету, готова к внедрению, если:

Управляющая команда понимает и суть процессного подхода, и необходимость его внедрения, и сопряженные с таким внедрением риски сложности, и свою роль в подобном проекте.
В компании есть явная неудовлетворенность линейных руководителей и рядовых сотрудников «бардаком», сложностями в коммуникациях между подразделениями, взаимные претензии к качеству передаваемых друг другу результатов.
Чем крупнее компания, тем важнее в подобном проекте IT-составляющая, связанная с реальным контролем процессных KPI и SLA, организацией потоков информации…

Оксана Дажун, бизнес-тренер, директор Dajun Consulting:

Компания готова, если соответствует следующим критериям:

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

Ольга Якимова, бизнес-тренер, автор методик и проектов в области менеджмента и маркетинга:

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

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

Антон Соколов, технический директор IT-компании «Деасофт»:

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

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

Александр Гончаров, старший бизнес-архитектор ICL Services:

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

Владислав Моргунов, главный специалист отдела внедрения процессного управления «Сиам консалтинг»:

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

Каким компаниям вы отказываете в проекте по внедрению бизнес-процессов?

Антон Соколов, технический директор IT-компании «Деасофт»:

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

Ольга Якимова, бизнес-тренер, автор методик и проектов в области менеджмента и маркетинга:

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

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

Оксана Дажун, бизнес-тренер, директор Dajun Consulting:

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

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

Лично я и моя команда отказывают двум основным категориям:

«Нерешительным» компаниям, которые долго принимают решение и отнимают время у подрядчика. Существует семь шагов к успешному внедрению и алгоритм выхода на проект. Когда со стороны заказчика происходит отклонение от намеченных шагов и алгоритма, затягивается время, это выливается в удорожание проекта, так как каждое обращение и время переговоров закладывается в накладные расходы.
«Бедным» компаниям, которые хотят ужаться и выкинуть какие-то этапы из проекта. Раньше, в порывах добрых чувств и большом желании получить проекты, мы пытались совместно «вписаться в бюджет» и пойти на встречу. В итоге все обвинения в неудачах все равно сыплются на подрядчика. Я таким компаниям говорю – ищите начинающих консультантов в поиске первых проектов и упражняйтесь совместно, но и риски берите на себя.

Тимур Гасиев, антикризисный менеджер, эксперт в области АПК:

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

Почему внедрение бизнес-процессов может завершиться неудачно?

Антон Соколов, технический директор IT-компании «Деасофт»:

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

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

Ольга Якимова, бизнес-тренер, автор методик и проектов в области менеджмента и маркетинга:

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

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

Оксана Дажун, бизнес-тренер, директор Dajun Consulting:

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

Самые частые ошибки:

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

Константин Зусманович, управляющий партнер Financial Mechanics:

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

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

Кейсы неудачного внедрения бизнес-процессов

Александр Гончаров, старший бизнес-архитектор ICL Services:

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

Тимур Гасиев, антикризисный менеджер, эксперт в области АПК:

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

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

Отсутствовал персонал для работы в данном канале.
Не хватало опыта работы в подобном канале.
Качество не соответствовало.
Российский аналог «Чикаго» оказался непригодным для использования.
Компания в целом была не готова к внедрению новых процессов. Менеджеры не смогли придерживаться установленной модели. Выделенных финансов оказалось недостаточно.

Источник

Усложнение бизнес-процессов, вызванное влиянием информационных технологий, заставляет компании меняться. Место проектного подхода и сложных иерархических структур занимают гибкие процессы управления и формирования «творческих коллективов». Однако внедрение Agile-методов может не дать ожидаемого результата. О подводных камнях процесса трансформации организационной структуры рассказал управляющий партнер компании «Ионов и Партнеры» Алексей Ионов.

1

2

04/10/2018

Переход на Agile: внедрять нельзя откладывать

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

Внедряя Agile в организациях, мы специализируемся на подходе Scaled Agile Framework® (SAFe®). Компании, перешедшие на SAFe, декларируют в среднем рост мотивации сотрудников на 10–50%, повышение производительности на 20–50%, снижение количества дефектов на 25–75% и, самое важное, ускорение доставки продукта до рынка на 30–75%

Алексей Ионов
управляющий партнер компании «Ионов и Партнеры»

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

Трансформация команды

Справка

В Agile-организации могут присутствовать следующие роли:

Product Manager, или менеджер продукта;
Product Owner, или владелец продукта;
Scrum Master , или сервис-лидер команд;

Agile coach/Change agent, или лидер-коуч изменений;
Competency/community leader, или лидер компетенции/сообщества;
Development Team member, или член команды разработки;
Business Owner/Business Partner/Stakeholder, или представитель бизнеса зарабатывающего подразделения;
и т.д…

подробнее

Поэтому важно, чтобы «центр» пересмотрел взгляды на систему управления.

Менеджеры должны стать лидерами, а не начальниками

«Грабли» Agile-трансформации

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

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

Этапы Agile-трансформации

Для первого запуска мы выбираем функционально обособленные бизнесы, подразделения или продукты. Благодаря этому возникает меньше проблем с тем, что одна часть компании работает по-новому, а другая — по-старому. Потом берем следующую организационную единицу, затем еще одну… И так постепенно трансформируем всю компанию.

Затраты vs результаты

Источник