Вирусный менеджмент что это

Обновлено: 19.04.2024

Наступает осень. Пора заниматься бизнес процессами.

Вообще-то, этим заниматься всегда пора, но осень – это особое время года для этого. Потому что…

Итак, осень. Апчхи! На Вас кто-то чихнул. Кхе-кхе! Это уже с другой стороны. Нравится? Наверное, не очень.

Почему? Заболеть не хочется, болеть – вредно для здоровья. А что делать? На дворе эпидемия сезонного гриппа…

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

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

Вирусы в менеджменте

В менеджменте тоже есть свои вирусы и микробы. Они сначала живут внутри одного отдельно взятого процесса или подразделения. Потом кхе-кхе, и заразился соседний процесс или подразделение. Затем следующий, следующий… Пока не случится: а-а-апчхи! Уже на клиента. И клиент зачихал и закашлял от заболевшей компании. Вот она – эпидемия вируса ИЗМЕНЧИВОСТИ. Так называется этот зловредный микроорганизм системы менеджмента.

Вирус изменчивости мешает всем делать так, как это задумано.

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

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

Главное для нас, для менеджмента, чтобы был иммунитет против вируса изменчивости. Иначе несдобровать клиенту. Болезнь изменчивости вылезет наружу, если у компании нет иммунитета. И заразит клиента. Будет ли он этим доволен? Вряд ли…

А у Вас в компании есть вирусы изменчивости?

Убийственный менеджмент

Природа рака еще не исследована до конца. Но многое уже известно.

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

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

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

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

А Вы умеете слышать других?

Ложные опасности в менеджменте

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

А менеджмент? Может ли процесс (функция) системы менеджмента реагировать на мнимые опасности и ложные сигналы? Конечно, может, поскольку природа иммунитета против вируса изменчивости системы менеджмента во многом аналогична природному иммунитету.

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

…Упрощать сложно. Опять-таки попробуем это сделать.

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

Управление проектами, связанными с IT, осложнено мифами и сказками вокруг индустрии программирования.

IT (сокращение от англ. Information Technology) — информационные технологии.

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

Умение абстрагироваться от подобных мифов приходит с опытом.

Миф об уникальности отрасли производства программного обеспечения

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

Законы развития, становления и окупаемости проектов при написании программ, сайтов, автоматизированных систем управления – те же.

Поэтому разговоры об уникальности разработчиков ПО, специфике управления проектами, особых путях развития бизнеса — не более чем миф.

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

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

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

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

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

Миф о запредельной сложности программирования

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

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

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

Чем это сложнее, чем, скажем, опытный станочник, работающий за пультом управления обрабатывающего центра?

Источник фото: Кубаньжелдормаш

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

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

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

И кто теперь виноват?! Кто создал условия будущей неопределенности для получения конечного результата проекта?

Миф о великом программисте

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

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

Ну, а если мы, менеджеры проектов, можем сами все спланировать, расставить по полочкам, сформировать команды программистов так, чтобы были какие-то перекрестные разработки, где есть возможность сравнивать качество работы, производительность труда и прочее – вот тогда великость программистов проходит сама по себе.

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

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

Разработчик программного кода не должен быть главным в проекте

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

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

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

В любом бизнесе, в том числе и в HI-TEC бизнесе выигрывают не инженеры, а профессиональные бизнесмены и высококвалифицированные менеджеры. Как, собственно, и везде.

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

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

Единое сервисное окно

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

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

Оптимизации ради

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

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

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

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

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

Опыт ИТ — бизнесу

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

Один ответ — ITSM

Подобные проекты охватили подразделения инженерного обслуживания магазинов в рознице, АХО в офисах, службы качества и АСУТП на производстве, бухгалтерию, отдел управления персоналом, а также различные технические службы и соответствующие сервисы.

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

Устранение болевых точек

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

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

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

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

Улучшение бэк-офиса

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

Подводные камни

Чтобы избежать серьезных трудностей при внедрении сервис-менеджмента, Дмитрий Рубин, руководитель по развитию направления Service Desk компании Naumen, рекомендует в первую очередь объяснить сотрудникам, что они являются ценными для компании внутренними поставщиками сервисов и что от их труда напрямую зависит конечный результат деятельности всей компании, ее эффективность и бизнес-показатели, поэтому работа сотрудников должна быть формализована и максимально оптимизирована. Потребитель или заказчик услуг любого сервисного подразделения, в свою очередь, должен четко понимать, какой именно результат он получит (это будет описано в каталоге услуг конкретного сервисного подразделения), в какие сроки и с каким качеством (это будет зафиксировано в SLA).

Читайте также: