ОБРАТНАЯ СВЯЗЬ

Удивительно, но все, что написано в статье Арама Пахчаняна «Внедрение систем электронного документооборота: проблемы и решения» (№ 01, 2002), мы переживаем в нашей компании. А еще удивительнее, что, не читая ничего подобного раньше, мы начали использовать все перечисленные в статье десять приемов преодоления общих проблем внедрения СЭД. Единственное, о чем хотелось бы узнать подробнее, так это об основах организации пилотного проекта, а точнее — понять, с какого пилотного проекта можно было бы начать работы по созданию системы электронного документооборота в самом сердце любой организации — в канцелярии. Электронная почта у нас есть, и мы с ней работаем, регистрация документов ведется в электронных журналах. Мы создали даже электронную контрольную картотеку, сканируем входящие документы, постепенно создаем электронный архив, а вот с движением документов — проблема. Что делать дальше? То, что система документооборота необходима — это бесспорно. Но как сделать следующий шаг? Буду рада обменяться опытом со своими коллегами из служб делопроизводства.

Прочитав статью Павла Сахарова «Rational Rose, BPwin и другие — аспект анализа бизнес-процессов» (№ 11, 2000) и дискуссию, развернувшуюся на сайте — там, где статья опубликована в электронном виде, еще раз убедился: сколько людей, столько и мнений. И в принципе все правы, предпочтительным является тот инструмент, которым лучше всего владеешь. Поэтому жаркие споры по вопросу достоинств и недостатков инструментов бессмысленны, хотя, если речь идет только о моделировании бизнес-процессов и их реинжениринге (не касаясь их автоматизации), я бы предпочел SADT.

Статья Виктора Когаловского «Происхождение ERP» (№ 05, 2000) мне понравилась тем, что в ней изложены основные особенности построения систем класса MRP/MRP II/ERP в достаточно логичной и понятной форме, что выгодно отличает ее от прочитанного на эту тему ранее. Для меня важно сравнение своих знаний и опыта с опытом других людей, интересующихся этой стороной интеграции ИТ в бизнес предприятий. Очень хотел бы подробно узнать об успешном внедрении систем MRP/MRP II/ERP в бизнес российских компаний, особенно в области страхования.

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

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

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

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

Мы попросили высказать свое мнение автора обсуждаемой статьи — Виктора Галактионова, вице-президента и главного системного архитектора ОАО «Альфа-банк». Приводим его комментарий.

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

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

Самый лучший способ понять важность этой проблемы — оказаться в чрезвычайной ситуации (лучше, конечно, учебной) и посмотреть со стороны, как бизнес будет себя вести в этих условиях. К сожалению, в отдельных случаях это осознание не приходит даже после выхода из чрезвычайной ситуации. Как водится, наказываются невиновные, награждаются непричастные, но выводы на будущее не делаются. Почти шесть лет назад в одном из крупнейших московских банков была объявлена чрезвычайная ситуация (поступил звонок о заложенной в здании мине). Опережая события, скажу, что полученная информация в результате не подтвердилась. Анализ действий сотрудников банка выявил огромную массу как забавных, так и весьма печальных ошибок. Вначале все сотрудники банка сочли это «сентябрьской» (послеотпускной) шуткой. Только после подключения к процессу принудительной эвакуации грозных сотрудников службы безопасности бизнес осознал, что это не шутка. Заведующий кассой не знал, как нужно себя вести в этой ситуации, и поэтому перед тем, как покинуть кассу, запустил штатную ежедневную процедуру «закрытие кассы», включающей пересчет наличности и подготовку всей необходимой документации и отчетности. (Забавно, не правда ли? Здание под угрозой обвала, а кассиры сидят в своих закрытых «окошечках» и пересчитывают наличность.) Реально обстоятельства, в которых находился в тот момент банк, относились к сценарию «потери административного контроля над зданием». Это касается также ситуаций, возникающих, например, когда в округе засели снайперы. При этом сценарии вся программная и техническая инфраструктура (серверы, сетевое оборудование, программы и пр.) продолжают исправно работать. Однако в процессе последовавшего после этой ситуации разбора полетов выяснилось, что в тот момент за пределами банка существовала только одна неофициальная копия базы данных четырехмесячной давности, на которой штатные разработчики отлаживали новые программы. Если бы информация подтвердилась, не думаю, что банк продолжал бы работать на московском рынке по сей день.

Бизнес часто любит жонглировать цифрами, утверждая, например: «У нас надежность три девятки» (имея в виду, что надежность информационных систем составляет 99,9%). Однако элементарный расчет показывает, что 0,1% составляет в совокупности в год почти девять часов простоя. Задайте владельцу бизнеса или руководству компании вопрос, устроит ли его, если всего один раз в год система будет останавливаться на девять часов кряду посреди рабочего дня, причем не планово, в субботу или в воскресенье, а совершенно случайным образом, например в последний день предоставления обязательной отчетности или в день погашения крупного кредита. Полагаю, что не каждый московский банк выдержит остановки системы расчетов даже на 15 минут перед закрытием пятого рейса (для некоторых банков четвертого)*.

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

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

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