ИНФОРМАЦИОННЫE ТEХНОЛОГИИ В БАНКE 2003 11

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

Проблемы тестирования

Рассмотрим некоторые типичные ошибки, совершаемые организациями в результате попыток провести эффективное тестирование программного обеспечения. Эти ошибки можно разбить на 4 категории.
1. Неправильное понимание роли тестирования. Назначение тестирования заключается в обнаружении дефектов продукта. В связи с этим важно хорошо понимать критичность тех или иных дефектов при планировании тестирования, при описании дефектов и подготовке рекомендаций.
2. Недостатки в планировании процесса тестирования. Во многих случаях при планировании тестирования чрезмерное внимание уделяется тестированию функциональности в ущерб тестированию потенциального взаимодействия и системных характеристик. Недостаточное внимание к документации по тестированию и к документации по инсталляции также довольно рискованно.
3. Неправильный подбор персонала для тестирования. Функцию тестирования нельзя поручать младшему персоналу. Группа тестирования должна включать специалистов ИТ по системе и конечных пользователей. Группа тестирования не может действовать эффективно, если ее состав не диверсифицирован.
4. Слабая методика тестирования. Точно так же, как программисты часто предпочитают кодирование написанию алгоритмов, тестирующий персонал часто уделяет чрезмерное внимание самим тестам в ущерб времени, отведенному на составление планов тестирования. Тесты должны дать подтверждение, что программный продукт способен адекватно выполнять свои функции.

Внедрение систем

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

Особенности внедрения

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

Организационные действия

На практике часто бывает так. Внедрение хорошо подготовлено: проведены многочисленные выверки данных, тестирование и многие другие, важные для внедрения, работы (о чем мы еще будем говорить далее). Но почему-то внедрение срывается, ком проблем растет с такой скоростью, что в один прекрасный момент большинству становиться ясно, что система не может быть внедрена. Проектная команда, менеджмент теряют веру, количество проблем от этого возрастает еще больше, и в конечном счете проект останавливается или приостанавливается высшим руководством.
Можно ли избежать этого? Ответ практикующих менеджеров проектов в 99,9% случаев - "да". Набор инструментов для достижения такого результата достаточно уникален и индивидуален и является во многом профессиональным ноу-хау (Know-How) руководителя проекта. Мы же рассмотрим некоторые основные составляющие таких организационных действий, которые позволяют сделать даже проблемное внедрение успешным.
Снятие противоречий и конфликтов. Первый вопрос, который необходимо прояснить, - всем ли нужно внедрение как в самой организации, так и среди подрядчиков? Кому оно невыгодно по тем или иным причинам? Кто против в настоящее время или был против на ранних стадиях проекта? Кто не принимал участия? Даже это может быть важно, потому что успех одного руководителя может автоматически снижать авторитет тех, кто не верил в исход проекта или был против него. Не стоит искать конфликты только среди руководства, они могут быть и на более низком уровне и при этом иметь очень большое значение. Задача руководителя проекта состоит в том, чтобы не только найти все эти центры противоречий и конфликтов, но и свести их на нет или по крайней мере добиться, чтобы их влияние на проект было минимальным.
Прояснение недопониманий и выработка согласованных подходов. Даже там, где нет предпосылок для конфликта, он может возникнуть по причине недопонимания. Внедрение является сложной задачей, и поэтому неминуемо в процессе работ, а особенно на их завершающей стадии, возникают такие ситуации, когда, не решаясь задать лишний вопрос, те или иные участники процесса просто не понимают смысл определенных действий или понимают его неправильно. Задача руководителя проекта - не только добиться того, чтобы количество таких недопониманий было минимальным, его задача также состоит в том, чтобы инициировать процедуры согласования позиций, их обсуждения и понятного и доступного формального закрепления в бумажной форме. Он должен как можно больше задавать вопросов всем участникам, чтобы добиться в конце концов одинаковых и согласованных позиций и полного понимания участниками и заинтересованными сторонами того, что происходит.
Прояснение формальной (юридической) позиции - тоже важная составляющая организационных действий. Выполненная до начала внедрения, посредством дополнительного анализа существующих формальных или договорных отношений между сторонами, она способна оказать реальную помощь в реализации двух предыдущих пунктов. Инициатором этой работы должен выступать руководитель проекта. При выявлении неясностей в формальных отношениях сторон их проясняют обязательно до начала внедрения, чтобы не приостанавливать его или не служить еще одним дополнительным риском.
Онлайн-менеджмент и контроль. Во время внедрения осуществляются постоянный надзор и контроль со стороны высшего менеджмента за происходящим. Он должен быть организован в онлайн-режиме, то есть участники проекта, его руководство имеют приоритетное право на взаимодействие с высшим менеджментом организации. Контроль должен осуществляться на оперативной и регулярной основе. Заседания управляющего комитета должны проводиться чаще, чем при обычной работе, и не реже одного раза в неделю. Не исключен и ежедневный вариант. Формальная отчетность и информация по ходу проекта должна быть доступна всем заинтересованным сторонам также на оперативной основе.
Оперативный анализ рисков. Отдельно руководителем проекта с помощью ведущих экспертов по основным областям ведется анализ рисков внедрения. Его форма должна быть простой и понятной. Это может быть просто текстовый список проблем, где указывается следующая информация: кто инициировал занесение проблемы в список, ее номер (если есть), суть проблемы, ответственный за решение, дата регистрации проблемы, дата решения, кратко основные действия по решению, приоритет и текущий статус (решена или нет). Такой список очень помогает руководителю проекта не забывать обо всех возникающих проблемах и в тоже время является инструментом контроля и давления на исполнителей, ответственных за решение.
Мотивация персонала на достижение результата. Возможно, самый главный пункт - это мотивация всех участников проекта и прежде всего его непосредственных работников на достижение результата. Мы уже останавливались на основных подходах по мотивации, когда рассматривали управление ИТ-персоналом, поэтому не будем здесь повторяться.
Широкое информирование заинтересованных сторон. Отдельная задача в ходе внедрения - информирование всех заинтересованных сторон, включая обычных сотрудников организации, о ходе и статусе работ. При недостатке информирования проект обрастает слухами, которые будут очень мешать в работе. С другой стороны, поддержка со стороны всей организации очень полезна для работы, является дополнительным источником мотивации. Но это возможно только при наличии информации и понимания, в противном случае отношение будет очень негативным.
Качественное и детальное планирование и обеспечение ресурсами. Планирование важно всегда, но на этапе внедрения оно имеет повышенное значение. Помимо этого целесообразно иметь небольшой резерв ресурсов, которые могут быть временно сняты с других работ или привлечены на отдельные участки со стороны. Все стандартные методики управления ресурсами, такие, как сетевое планирование, использование методики критического пути, должны использоваться руководителем проекта для получения информации и оперативного принятия решений по переброске ресурсов или их увеличению.

Подготовка к внедрению

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

Начало рабочей эксплуатации

Начало рабочей эксплуатации является самым критическим моментом в проекте. Фактически успешный старт и работа в системе хотя бы в течение нескольких дней означают успех проекта. Конечно, наличие большого количества недоработок, кажущиеся неудобства в работе, периодические сбои не позволяют сказать об этом сразу, но все эти проблемы намного более просты в решении, чем поддержание двух информационных систем и постоянная синхронизация данных в них.
Но начало рабочей эксплуатации и, как следствие, отказ от поддержки старой системы не могут основываться только на желании это сделать. Малейший сбой приводит к откату к предыдущему состоянию, к возврату эксплуатации старой системы, поскольку ни один руководитель не возьмет на себя ответственность продолжать эксперимент, когда, например, у него не проходят обработку клиентские платежи или неправильно рассчитываются процентные ставки по депозитам более чем в течение 10 минут.
В зависимости от размера организации возможны два варианта перехода на рабочую эксплуатацию. Для организации с количеством сотрудников до 100 человек, как правило, применяется тотальный переход. Все пользователи в определенный день (обычно пятницу, чтобы было время для устранения ошибок) начинают работу в новой системе. Основными показателями успешного перехода на новую систему являются отсутствие задержек приема документов у клиента, своевременная отправка платежей, получение правильного баланса.
В случае, если внедряемая система решает большой спектр задач, количество пользователей более 100, необходим поэтапный переход. Он может осуществляться в следующей последовательности:
- запуск интерфейса взаимодействия с внешними платежными системами, маршрутизация платежей филиалов;
- формирование баланса и прочей ежедневной и оперативной отчетности;
- ввод простейших платежных документов в систему пользователями, ведение расчетно-кассового обслуживания;
- учет сложных операций (покупка-продажа валют);
- автоматическое начисление процентов и платы за обслуживание;
- формирование документопотока в соответствии с перспективной моделью организации, изменение обязанностей сотрудников, участвующих в расчетно-кассовом обслуживании клиентов и собственных платежей банка;
- учет операций физических лиц;
- учет внутренних операций банка: расчет зарплат, ведение хозяйственных договоров, учет основных средств;
- учет и ведение кредитов банка;
- учет прочих операций банка, включая торговые операции на бирже. Такая последовательность позволяет минимизировать последствия озможных сбоев и дает время команде внедрения сосредоточиться на одной задаче, а не распылять свои силы на решение всех проблем.

Завершение проектов

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

Анализ рисков при реализации проектов

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

Типы рисков в информационном проекте

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

Идентификация рисков

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

Таблица 16

Оформление таблицы рисков проекта

------------------------T------T---------T---------T----------T---------¬
¦ Наименование риска ¦ Тип ¦ Вероят- ¦Приоритет¦ Сумма ¦Временные¦
¦ ¦ ¦ность, в ¦ ¦ущерба, в ¦потери, в¦
¦ ¦ ¦ % ¦ ¦ руб. ¦ днях ¦
+-----------------------+------+---------+---------+----------+---------+
¦Увеличение количества¦ PS ¦ 60 ¦ 3 ¦ 2 000¦ 2 ¦
¦пользователей ¦ ¦ ¦ ¦ ¦ ¦
+-----------------------+------+---------+---------+----------+---------+
¦Изменение выходных¦ RE ¦ 60 ¦ 2 ¦ 14 000¦ 4 ¦
¦отчетных форм ¦ ¦ ¦ ¦ ¦ ¦
+-----------------------+------+---------+---------+----------+---------+
¦Неподготовленный ¦ PR ¦ 30 ¦ 4 ¦ 2 000¦ без ¦
¦конечный пользователь ¦ ¦ ¦ ¦ ¦ затрат ¦
+-----------------------+------+---------+---------+----------+---------+
¦Противодействие ¦ PR ¦ 10 ¦ 2 ¦ 15 000¦ 10 ¦
¦конечных пользователей¦ ¦ ¦ ¦ ¦ ¦
¦внедрению системы ¦ ¦ ¦ ¦ ¦ ¦
L-----------------------+------+---------+---------+----------+----------

--------------------------------¬ --------------------------------------¬
¦ Расшифровка типов ¦ ¦ Приоритеты ¦
+----T--------------------------+ +---T----------T----------------------+
¦ PS ¦изменения размера системы ¦ ¦ 1 ¦Катастрофа¦> 100 000 руб. > 20¦
+----+--------------------------+ ¦ ¦ ¦дней ¦
¦ RE ¦изменения постановки задач¦ +---+----------+----------------------+
+----+--------------------------+ ¦ 2 ¦Критично ¦> 10 000 руб. > 3 дней¦
¦ PR ¦проблемы с персоналом ¦ +---+----------+----------------------+
L----+--------------------------- ¦ 3 ¦Проблема ¦> 1000 руб. > 1 дня ¦
+---+----------+----------------------+
¦ 4 ¦Возможно ¦< 1000 руб. < 1 дня ¦
¦ ¦игнориро- ¦ ¦
¦ ¦вание ¦ ¦
L---+----------+-----------------------

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

"Формула 1"

"Формула 2"

Таблица 17

Расчет уровня рисков и их влияния

------------------------------------------------------------------------¬
¦ Итоговая таблица по приоритетам ¦
+---------T---------------------T--------------------T------------------+
¦Приоритет¦ Вероятность, ¦ Средний денежный ¦Потери времени, в ¦
¦ ¦ % ¦ ущерб, руб. ¦ днях ¦
+---------+---------------------+--------------------+------------------+
¦ 1 ¦ 0 ¦ 0¦ 0 ¦
+---------+---------------------+--------------------+------------------+
¦ 2 ¦ 64 ¦ 9900¦ 3,4 ¦
+---------+---------------------+--------------------+------------------+
¦ 3 ¦ 60 ¦ 1200¦ 1 ¦
+---------+---------------------+--------------------+------------------+
¦ 4 ¦ 30 ¦ 600¦ 0 ¦
+---------+---------------------+--------------------+------------------+
¦ Итоговая таблица по категориям ¦
+---------T---------------------T--------------------T------------------+
¦ PR ¦ 37 ¦ 2100¦ 1 ¦
+---------+---------------------+--------------------+------------------+
¦ RE ¦ 60 ¦ 8400¦ 2,4 ¦
+---------+---------------------+--------------------+------------------+
¦ PS ¦ 60 ¦ 1200¦ 1,2 ¦
+---------+---------------------+--------------------+------------------+
¦ Общий итог ¦
+---------T---------------------T--------------------T------------------+
¦ ¦ ¦ 11 700¦ 4,6 ¦
L---------+---------------------+--------------------+-------------------

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

Снижение потерь

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

Таблица 18

Оформление плана противодействия рискам

------T--------T----------------T---------------T--------------T----------------T------------------¬
¦ N ¦Вероят- ¦ Ущерб ¦ Подробное ¦ Профилактика ¦ Механизм ¦ Что делать ¦
¦ ¦ ность ¦ ¦ описание ¦ ¦ мониторинга ¦ ¦
+-----+--------+----------------+---------------+--------------+----------------+------------------+
¦ 1 ¦ 40% ¦2-кратное увел.¦Потеря интереса¦Максимальная ¦Постоянное ¦Попросить ¦
¦ ¦ ¦сроков. ¦у пользователей¦популяризация ¦обсуждение с¦руководство ¦
¦ ¦ ¦Профилактика = 1¦к развитию¦проекта, ¦группой ¦заказчика отметить¦
¦ ¦ ¦чел/д; ¦системы из-за¦построение ¦внедрения ¦подразделения, ¦
¦ ¦ ¦эффект Р = 20%; ¦угрозы ¦связи между¦отношения ¦обеспечивающие ¦
¦ ¦ ¦преодоление =¦сокращения ¦эффектом от¦пользователей к¦наибольшую ¦
¦ ¦ ¦6000 руб./отдел;¦ ¦проекта и¦проекту ¦поддержку проекта.¦
¦ ¦ ¦эффект = Р/2 ¦ ¦ростом доходов¦ ¦Рассмотреть ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦исключение ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦сопротивляющихся ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦подразделении из¦
¦ ¦ ¦ ¦ ¦ ¦ ¦участия в проекте ¦
+-----+--------+----------------+---------------+--------------+----------------+------------------+
¦ 2 ¦ ¦ ¦ ¦ ¦ ¦ ¦
+-----+--------+----------------+---------------+--------------+----------------+------------------+
¦ 3 ¦ ¦ ¦ ¦ ¦ ¦ ¦
+-----+--------+----------------+---------------+--------------+----------------+------------------+
¦ 4 ¦ ¦ ¦ ¦ ¦ ¦ ¦
L-----+--------+----------------+---------------+--------------+----------------+-------------------

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

Снижение затрат в проектах

Ожидаемая в следующем году новая волна изменений в правилах бухгалтерского учета приведет российские кредитные организации к необходимости серьезной доработки или смены информационных систем. Безусловно, опыт, полученный банками в области автоматизации за прошедшее десятилетие, позволит существенно сократить потери от изменения правил и механизмов учета. Рассмотрим различные приемы, направленные на сокращение затрат при выполнении различных проектов, связанных с изменениями в текущей деятельности работающей организации.
Одним из самых эффективных путей сокращения проектных издержек является сокращение требуемых ресурсов и использование вместо них уже имеющихся.
К дополнительным ресурсам проекта, то есть тем, на которые необходимы дополнительные затраты, в кредитной организации можно отнести:
* персонал;
* помещение;
* вычислительную технику и программное обеспечение;
* коммуникации.
Как искать человеческие ресурсы для проекта, мы уже говорили. Резервом помещений в банке являются, как правило, переговорные комнаты и комнаты для конференций и заседаний. Но если проект требует долгосрочного использования помещения, то аренды или покупки дополнительного помещения скорее всего не избежать.
Резервом вычислительной техники может являться устаревшее оборудование. Часто в отделах автоматизации скапливаются устаревшие компьютеры и техника. Приведем примеры решения подобных задач.
Временному сотруднику на время проекта требуется компьютер. Можно предложить ему старый компьютер. В 70% случаев этого будет достаточно. Другой вариант: взять компьютер сотрудника, находящегося в отпуске, и заменить жесткий диск. Если сотрудник возвращается из отпуска до завершения проекта, можно переставить данные участника проекта на другой компьютер. Более простой вариант распределенного использования вычислительной техники будет доступен, если в организации для работы используются сетевые диски.
Набор задач, реализуемых на одном мощном сервере, можно разбить и использовать маломощные компьютеры. Например, почтовые и интернет-серверы для небольших рабочих групп могут быть реализованы на устаревших рабочих станциях.
Следует рассмотреть возможность обновления (upgrade) вычислительной техники. Иногда для эффективной работы приложения достаточно просто увеличить объем оперативной памяти, стоимость которой невысока.
В отношении программного обеспечения следует придерживаться позиции противостояния увеличению количества используемых программ. Все задачи надо стараться реализовывать в уже имеющихся приложениях. Особенно это относится к системам управления базами данных. Если банк работает на MS SQL Server, проект должен реализовываться на этой платформе, а не на ORACLE, и наоборот. В противном случае дополнительные затраты возрастут на суммы от $5 до 100 тысяч в зависимости от размеров организации.
Для коммуникаций также существуют некоторые резервы. Как правило, это несанкционированный трафик: от сетевых компьютерных игр до блужданий в компьютерных сетях или личных разговоров по телефону. Следует осуществлять контроль передаваемой информации по компьютерным сетям. Даже если возможности такого контроля нет, можно создать его видимость. Эффект может оказаться неожиданным и крайне позитивным для проекта.
Рассмотренный нами список резервов не является полным. Каждая организация имеет свои секреты и приемы работы, которые могли бы его дополнить. Некоторые из них, возможно, не дадут эффекта. Однако время "шальных" денег прошло, и надо использовать любую возможность их экономии, не забывая при этом, что цель - реализация проекта, а не экономия средств.

Методы поиска решений

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

Анализ задачи

Итак, первый этап - это анализ. Основная цель первого этапа - переход от расплывчатой ситуации к четко построенной и предельно простой схеме задачи. Этап содержит семь действий, позволяющих четко сформулировать задачу и выявить основные противоречия.
1. Записать условия мини-задачи (без специальных терминов) по следующей форме.
Участники процесса. Указать цели и задачи каждого участника, его возможности и связи. Указать особенности каждого участника и (в случае, если участник - организация или любая другая группа людей) его составляющие.
Противоречия. Перечисляются все противоречия.
Что необходимо при минимальных изменениях. Указать результат, который должен быть получен. Мини-задачу получают из общей проблемы, вводя ограничения: все остается без изменения или упрощается, но при этом задача достигает своего решения или исчезает противоречие. Переход к мини-задаче не означает, что начато решение основной задачи. Наоборот, введение дополнительных ограничений (результат должен быть получен из ничего) ориентирован на обострение конфликта и заранее отрезает пути к компромиссным решениям.
Пример мини-задачи.
Участники процесса:
сотрудник "А". Хороший специалист, знает учет, пользуется уважением в коллективе;
сотрудник "В". Имеет связи за пределами организации. Однако груб с коллегами, имеет ряд недостатков.
Противоречие: между ними имеется скрытое соперничество, выдвижение одного может привести к увольнению другого. В случае увольнения сотрудник "А" может увести с собой и других сотрудников отдела, что существенно нарушит деятельность организации. В случае увольнения сотрудника "В" будет потерян важный клиент.
Необходимо при минимальных изменениях: назначить нового руководителя отдела, удержав обоих сотрудников в организации.
Термины и понятия в описании задачи следует заменять простыми словами без дипломатических уверток. Например, фразу "имеет связи" лучше поменять на описание этих связей: "супруг является директором данной фирмы"; "привел этого клиента в банк (имя); знакомство (учились в одном классе с начальником отдела маркетинга)". Согласитесь, что описание влияния сотрудника "В" в фирме клиента существенно расширяется.
2. Анализ конфликтующей пары.
В нашем случае конфликтующей парой являются сотрудники "А" и "В". Данный этап требует дополнительно проанализировать данных сотрудников, учитывая следующие параметры:
* развитие ситуации во времени. В рассматриваемом случае необходимо оценить дальнейший карьерный рост каждого из них, а также их ожидания в продвижении по карьерной лестнице. Например, если очевидно, что один из сотрудников долго на предлагаемой должности не задержится, это может существенно повлиять на принятие вашего решения;
* силу связи участников конфликта с окружающей средой. Здесь надо еще раз оценить, насколько сильно участник конфликта может оказывать влияние на окружающих;
устойчивость участников конфликта к психологическому воздействию. Данный пункт отсутствует в АРИЗ, поскольку технологические процессы не поддаются психологическому воздействию, однако в гуманитарной области это воздействие часто оказывается решающим.
3. Построение графической схемы конфликта.
Очень многие технологии, связанные с поиском решений, рекомендуют графическое отображение процессов. Это объясняется повышенной восприимчивостью человеческого мозга к графическим образам. АРИЗ также предполагает построение подобных графических схем. Какого-то единого стандарта, как, например, в IDEFO, здесь нет. Единственное условие - простота и понятность.
Шаги 2 и 3 уточняют общую формулировку задачи. Поэтому после третьего шага необходимо вернуться к первому, проверить несоответствия и скорректировать их.
4. Выбор типового решения, которое обеспечивает наилучшее осуществление главного процесса.
Этот шаг не приводит к полному решению задачи, однако заставляет провести оценку конфликта и его последствий. Насколько на самом деле увольнение одного из рассматриваемых сотрудников критично для организации? На какие затраты может пойти организация для разрешения данного конфликта? В дальнейшем оценка ущерба от конфликта станет одним из основных параметров поиска решений
5. Построение модели самого плохого развития ситуации. Данный шаг является развитием предыдущего во времени, поскольку значение разовых потерь может быть существенно меньше, чем ущерб, который получит организация впоследствии. Например, в нашем случае это могут быть неуверенность и чувство несправедливости у оставшихся сотрудников, что может привести их к поиску нового места работы.
6. Окончательная формулировка задачи.
Все вышеперечисленные шаги позволяют провести окончательную формулировку задачи, которая должна содержать в себе помимо описания мини-задачи следующие составляющие:
- участников конфликта;
- оценку ущерба, равную наихудшему развитию ситуации при выборе лучшего стандартного решения;
- требования к Х-элементу (под Х-элементом подразумевается изменение в системе, направленное на достижение поставленной цели).
В нашем случае задача будет примерно такой: сохранить профессиональный коллектив отдела, повысив реального лидера коллектива, и при этом не потерять клиента, представитель которого претендует на должность руководителя.
1. Проверить возможность применения стандартных решений подобных задач из разных областей жизни.
В стандартном описании "алгоритма решения задач" систематизация стандартных решений является достаточно большой областью теории, выходящей за рамки данной главы. Для простоты мы воспользуемся простым перебором возможных решений проблемы, когда два объекта стремятся занять одну область. Вот возможные решения.
Разнесение во времени. Сначала вакансия отдается одному сотруднику, затем он переводится на другую должность, и место отдается второму сотруднику.
Разделение области на подобласти. Под данным решением подразумевается разделение основных атрибутов вакансии руководителя на два списка и распределение их между участниками конфликта. Например, сотрудник "А" получает реальную власть в принятии решений, распределении работ, ответственность за результат. Сотрудник "В" получает звание и администраторские функции. Реально этого можно достичь, выделив сотрудника "А" в отдельный проект, контролируемый высшим руководством организации.
Дублирование области. Это часто применяемое решение, заключающееся в создании должности специально под сотрудника с целью удовлетворения его амбиций.
Не решать задачу. Поскольку негативные последствия в рассматриваемом конфликте начинаются только после принятия решения, то одним из решений может стать его отсутствие, что, возможно, приведет к отсутствию конфликта. Учитывая динамичность области задачи, можно ожидать изменения рассматриваемой системы и исчезновения конфликта решений.
Удаление лишнего звена системы, приводящего к конфликту. Если еще раз внимательно перечитать условия задачи, то становится видно, что организации не интересен сам сотрудник "В". Условия требуют сохранения клиента. Сотрудник является всего лишь связующим звеном. Возможно, следует пересмотреть условия задачи и рассмотреть новую задачу по созданию новой связи между организацией и клиентом без посреднических услуг сотрудника.
Помимо этих чисто технических решений для задач управления возможны и психологические решения. Среди них:
подмена цели. Данное решение включает в себя попытку убедить одного из сотрудников, что его настоящая цель заключается не в занимаемой должности, а, например, в финансовом благополучии. В результате, правда, придется повысить одному из них заработную плату;
отвлечение внимания. Увлечь сотрудника решением новой задачи или новым проектом, что сделает потерю должности не столь болезненной и не приведет к критической точке конфликта.
Нет сомнений, что существуют и другие решения рассматриваемой проблемы. Но, так или иначе, задача подобной сложности скорее всего будет решена именно на первом этапе, основной идеей которого является необходимость как следует разобраться в проблеме. Возможно, решение появится само собой. При рассмотрении следующих этапов мы усложним пример и рассмотрим, к каким неожиданным и красивым решениям может привести использование данного алгоритма.

Анализ ресурсов

Второй этап - анализ ресурсов. "Цель второго этапа - учет имеющихся ресурсов, которые можно использовать при решении задачи".
Второй этап состоит из трех шагов: определения оперативной зоны, определения оперативного времени и определения финансово-производственных ресурсов. В качестве примера для анализа будет рассматриваться проблема ликвидности активов: "Организации срочно требуются свободные средства для осуществления текущих платежей по договору, однако имеющиеся у нее активы являются низколиквидными. Необходимо найти решение преобразования данных активов в свободные средства с минимальными потерями в определенные сроки".
1. Определение оперативной зоны. В простейшем случае оперативная зона - это область, в пределах которой возникает конфликт, указанный в модели задачи, ограниченная правовыми и этическими рамками. Границами этой зоны является свод обязательных правил, нарушение которых недопустимо при решении задач и. Наиболее часто используются следующие ограничения:
- соответствие законодательной базе - при описании данных ограничений следует четко определить области действия законов. Необходимо контролировать пересечение областей действия задачи и действия различных законов;
- соответствие нормам поведения в обществе и внутренним регламентам.
2. Определение оперативного времени. Оперативное время - это имеющиеся ресурсы времени: время до конфликта и время продолжительности конфликта.
В рассматриваемом примере время до конфликта - это время на подготовку операции перевода активов в свободные средства, время продолжительности конфликта - это время, требуемое на саму операцию. Соответственно сумма обоих временных интервалов должна быть меньше времени до начала платежа.
3. Определение оперативных ресурсов (инструментов). Ресурсы - это средства, доступные в оперативное время в оперативной области для решения задачи. Применительно к задачам управления определяются следующие типы ресурсов:
* ресурсы времени;

<< Пред. стр. 11 (из 20) След. >>

Список литературы по разделу