Рубрика «управление изменениями»

Предисловие переводчика

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

Статья Алексея Жеглова, аккредитованного канбан консультанта (AKC) и тренера (AKT) рассказывает о том, как отслеживать здоровье проекта с помощью накопительной диаграммы потока и как определять рабочие элементы, чтобы диаграмма отображала действительно полезную информацию.
Читать полностью »

Ключевой проблемой любой организации являются изменения.

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

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

Если у вас проблемы с продажами, вам нужны изменения. Очевидно? Вроде да. Или продукты продаете не те, что нужны рынку, или их слишком мало, или слишком много, или сроки срываете, или качество — недопустимо низкое, или продавцы хамят клиентам – неважно, это причины. Чтобы эти причины перестали оказывать влияние на систему продаж, нужны изменения.

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

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

Чего воду в ступе толочь, вступления писать, сразу к делу.

Первый слой – кто хочет?

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

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

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

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

Воронка изменений - 1

Ой, не то. Вот так:

Воронка изменений - 2

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

Итак, первый, самый широкий слой воронки – те, кто поднял руку.Читать полностью »

Разница восприятия

Существует забавная разница в восприятии возможности изменения бизнес-системы между «низами» и «верхами».

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

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

Но в самом начале возражение было одно: мы – не менеджеры. У нас нет власти, а у менеджера – есть. Только он может все поменять. Только он понимает, что и как надо поменять в процессах, мотивации, целях, управлении и автоматизации. А мы – маленькие (ну и там еще много прилагательных было).Читать полностью »

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

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

Как мы побеждали бардак с железом и становились бюрократами с нуля - 1
Разница между документацией и базой знаний: документация говорит, что это устройство охлаждает воздух до +18 градусов по Цельсию, а база знаний подсказывает, что есть редкий баг, когда два датчика сразу показывают -51 тысячу градусов и устройство начинает лихорадочно греть воздух для серверов.

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

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

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

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

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

Суррогат – это когда сделали не то, что нужно бизнесу. Или не так, как нужно бизнесу.

Суррогаты – это самое страшное зло, происходящее сейчас с российским бизнесом и государственным управлением. Суррогаты – это лучший в мире киллер эффективности. Что особенно приятно, мы, программисты, на этот раз не в стороне – мы на самой оси зла.

С чего все начинается

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

Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.

Вариантов развития событий много, я приведу некоторые из них:
1. Программист говорит: согласуй с моим или своим начальником, тогда сделаю;
2. Программист говорит: напиши мне задачу/поручение/служебную записку, на бумаге или в информационной системе;
Читать полностью »

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

Описание проблемы

Я столкнулся со следующими проблемами при анализе существовавшего процесса:

• 80% задач поступает ad hoc
• приоритеты задач постоянно меняются
• нет возможности осуществлять планирование работ
• отсутствует гармоничность в развитии систем
• нет «установленных правил игры» при реализации изменений

image
Читать полностью »

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

image

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

Плюсы и минусы групп в общественных соцсетях для продвижения бренда компании.
Читать полностью »

Оказывается, из всех разработанных стратегий реализуется лишь 10%. В чем отличие успешных организаций, и что останавливает остальных?
image

Лет десять назад я был весьма удивлен, когда узнал, что только 30% внедрений ERP систем считается успешными. Три года назад я узнал, что успешны только 20% внедрений корпоративных социальных сетей (сейчас уже больше, потому что за это дело взялись мы). И вот, на прошлой неделе, читая книгу Джима Хоудена «Искусство вовлечения», я узнал, что есть вещи, которые внедряются еще хуже. Это стратегии развития компаний. И из всех разработанных стратегий реализуется только 10%.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js