Управление изменениями во время кризиса

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

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

Надо сказать, что опыт в этой области у нас большой и, к сожалению, весьма печальный. Впервые BPR был проведен еще в России в 1917 году. По истечении семидесяти с небольшим лет пришли к выводу, что проект был явно неудачным и его решили повторить. Произошло это в 1991 году, при этом явно поторопились. Надо было подождать несколько лет, поскольку BPR как инженерная дисциплина сформировалась только к середине 90-х годов. Речь шла о реинжиниринге корпораций, но, если разобраться, государство – это ведь тоже корпорация, только очень большая. Были исследованы недостатки, приведшие в свое время к огромному числу провальных проектов в этой области (порядка 70%), и предложены цельные методологии коренных преобразований бизнес-процессов компаний, которые позволили улучшить ситуацию в этой области.

CASE-системы

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

Проблемы проведения BPR (да и любых изменений в бизнесе) в свое время были двоякого рода: технические и человеческие. С технической точки зрения все было относительно просто. Для этого была принята (с некоторыми коррективами) методология разработки ПО вместе с соответствующими инструментальными средствами – CASE-системами (Computer-Aided Software Engineering).

Вообще, идея, лежащая в основе современных методологий разработки, достаточно проста и может быть выражена следующим образом. Прежде чем бросаться что-то делать руками (программировать), предлагается немного поработать головой для определения проблемы, которую предстоит решить, – этап моделирования бизнеса (концептуальное моделирование). После этого определить, что необходимо сделать для решения сформулированной проблемы, – этап анализа (логическое моделирование). Далее определить, как это "что-то" реализовать (желательно лучшим образом), – этап проектирования (разработка структурных схем и алгоритмов). И только после всего этого допускается давать волю рукам – этап реализации (программирование, отладка и тестирование). В результате устанавливается однозначное соответствие по всей цепочке "бизнес-ПО": модель бизнеса – модель ПО – архитектура ПО – алгоритмы модулей ПО – код ПО (прямой инжиниринг). При этом также однозначно можно пройти по этой цепочке и в обратном порядке (обратный инжиниринг или реинжиниринг). Иными словами, все в полном соответствии с "иконостасом" Захмана (John A. Zachman).


Рис. 1. Архитектура предприятия – каркас Захмана (John A. Zachman)

Несмотря на некоторую банальность приведенной выше идеи, далеко не всеми отечественными разработчиками она до сих пор принята на вооружение (по крайней мере, в полном объеме). В наличии у наших разработчиков имеются, как правило, лишь исходные тексты, описание структуры БД и описания отдельных аспектов бизнеса. Это характерно даже для тех подразделений ИТ, которые используют CASE-системы. Иными словами, прямой инжиниринг не проводился, значит, придется проводить обратный инжиниринг.

Конечной целью будет получение модели бизнеса – совокупности моделей бизнес-процессов и модели информационных потребностей этих бизнес-процессов. Если имеется CASE-система, то последнюю модель получить достаточно просто, поскольку все эти системы имеют средства реинжиниринга баз данных для получения модели информационных потребностей. Модели бизнес-процессов придется делать практически вручную. Если же CASE-системы нет, то вручную придется делать все, используя, к примеру, средства Visio и Word. Полученные модели бизнеса помогут понять существующее положение дел, а главное, потребности и возможности проведения необходимых изменений существующих бизнес-процессов для последующей их реорганизации. Для этих целей можно в полном объеме применить методологию BPR.

Моделирование бизнес-процессов

Но это все технические проблемы, а как уже говорилось, при проведении любых изменений бизнеса есть еще и проблемы, обусловленные человеческим фактором. Решение проблем первого типа может оказаться очень трудоемким, а вот второго типа – еще и крайне сложным. Причем, вне зависимости от того, применяется ли для проведения изменений классический BPR или реинжиниринг ПО. Решение проблем этого типа предлагались в таких дисциплинах, как психология и социология, но они носили чрезмерно академический характер. Практически эта проблема стала решаться в рамках подхода, названного "управление изменениями" (Change Management). Его варианты показаны в таблице 1.


Таблица 1. Классификация подходов к управлению изменениями

Управление изменениями отличается от академических подходов, во-первых, тем, что основано на практическом опыте, а во-вторых, поддерживается соответствующим ПО. Кроме того, разработаны модели зрелости управления изменениями (Change Management Maturity Model, www.change-management.com) и модели зрелости бизнес-процессов (Business Process Maturity Model, www.omg.org). По этим моделям зрелости можно понять текущее состояние дел вашего бизнеса и выбрать подходящий подход к изменениям (см.табл.1.) для достижения желаемого состояния.

Человеческий фактор

В чем же сложность в управлении изменениями? Все очень просто: все (за редким исключением) сотрудники вашей (и любой другой) компании будут сопротивляться всем без исключения предлагаемым изменениям. Известный эксперт в этой области Джеймс О’Тул выдвинул и обосновал целых тридцать три гипотезы того, почему люди противятся переменам (O’Tool J., "Leading Change: The Argument for Values-Based Leadership", New York: Ballantine Books, 1996). Главное заключается в страхе перед неизвестностью, что представляет собой суть человеческой природы. Как же с этим бороться?

Рассмотрим в самом общем виде отношение сотрудников любой компании к процессу проведения изменений. С этой точки зрения их иногда (существуют и другие варианты классификации) делят на три категории: "тигры", "ослы" и "акулы" (Ivar Jacobson etc., "The Object Advantage: business process reengineering with object technology", Addison-Wesley Publishing Company, 1995).

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

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

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

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


Рис. 2. Формы сопротивления к изменениям

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

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

Что касается сотрудников из категории "неопредилившихся", то, если их не удастся "перетянуть" в конструктивные категории, по крайней мере, следует, не допустить их перехода в деструктивные.

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

Что такое CASE-система
В последние годы на мировом рынке программных продуктов появилось много программных средств, называемых CASE-системами или CASE-средствами. Слово CASE представляет собой сокращение от Computer Aided Software Engineering. В русскоязычной литературе нет соответствующего общепринятого термина. С точки зрения ряда ИТ-экспертов есть два наиболее соответствующих оригиналу и назначению CASE-систем перевода: "Программная инженерия, поддерживаемая компьютером" и менее буквальный, но более отвечающий сути перевод "Средства разработки программ с помощью компьютера". Теоретическое осмысливание этого явления и его места в технологии программирования находится на очень ранних стадиях.
Рассмотрим спектр значений, фактически покрываемых термином "CASE-система", а так же его соотношение с классическим термином "среда программирования" и "среда разработки программ". Мы увидим, что при буквальном рассмотрении CASE-системой можно назвать всякую программную систему, помогающую в разработке программ, включая любой транслятор. Но реально к CASE-системам можно отнести системы, поддерживающие этап анализа проектируемого программного продукта и фиксацию результатов такого анализа в виде соответствующих спецификаций. По мере развития CASE этим термином начали обозначать различные программные средства, относящиеся к автоматизации проектирования и разработки программ.

— Вячеслав Рыбальченко, независимый ИТ-эксперт

2009.03.10
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".