Часть 3. Управление проектами в области ИТ
К оглавлению1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1617 18 22
При реализации проектов в области ИТ в первую очередь стоит помнить об их основной цели - содействии развитию бизнеса, внедрению передовых технологий и решений. Но эффективное развитие невозможно, если в организации не приветствуются инновации и нововведения. Поэтому цель - поддержка изменений. Но что такое изменения и зачем они нужны? Как управлять этим процессом? И какое все это имеет отношение к проектному управлению в области ИТ?
Одним из принципиальных моментов, определяющих эволюцию каждого менеджера и организации в целом, является осознание необходимости постоянных изменений. Как только организация хоть на время "останавливается" или просто уменьшает темп своего развития, она начинает сразу сдавать свои позиции.
Постоянные изменения стали одним из отличительных знаков нашего времени. Они затрагивают практически все области. Меняется сам уклад жизни, восприятие людей, хозяйственные отношения.
Непрерывно изменяющаяся внешняя среда уже сама по себе обусловливает для коммерческих организаций необходимость следовать всем новейшим тенденциям. Многие возразят, что "здоровый" консерватизм еще никому не мешал. Однако правы они будут лишь отчасти. Когда-то консерватизм, возможно, и был обязателен во многих сферах деятельности, но в настоящей экономической ситуации он является полным анахронизмом. Это можно хорошо проиллюстрировать на примере таких, как считалось раньше, консервативных сфер бизнеса, как банковское дело или страховой бизнес. Сегодня они отвергают большинство традиционных подходов и активно меняют практику своей работы, не боясь "кидаться в омут" неизведанного и нового. Связано это с тем, что, не отслеживая тенденции рынка, запросы потребителей, новейшие технологические достижения, сегодня невозможно удержать как собственные позиции, так и своего клиента, который становится более требовательным.
Не двигаться вперед - значит, двигаться назад. Этот тезис сегодня очевиден, но не так очевидны его предпосылки, а также причины возможного регресса. Попытаемся разобраться в них и обосновать необходимость постоянных преобразований.
Одной из основных причин такой необходимости можно назвать технологическую революцию последних десятилетий. Большинство других причин являются во многом следствиями глобальных изменений в научно-технической и технологических сферах. Именно они принципиально изменили картину гиперэкономического пространства, создав новую в истории человечества экономическую ситуацию, при которой потенциальное предложение на большинстве рынков существенно превышает спрос.
Практически всю историю человечества картина была обратной. Спрос в глобальном отношении был почти всегда ниже предложения, а на уровне отдельных рынков они уравновешивали друг друга в основном за счет ценового механизма. Кроме того, традиционная система экономических отношений в области макро- и микроэкономики базировалась на опыте предшествующих столетий. То есть при осуществлении деятельности в сфере производства или услуг, в том числе и в процессе менеджмента, не предполагалось, что предложение может в несколько раз превысить спрос или что спрос вообще будет отсутствовать.
Но картина неожиданно изменилась, и изменилась именно вследствие технологической революции, которая выразилась в резком росте производительности труда, перепроизводстве товаров и услуг, снятии коммуникативных и торговых барьеров, повышении уровня жизни в подавляющем большинстве стран, что в свою очередь кардинально изменило отношения производителей с потребителями, клиентами и, что вполне закономерно, в этой ситуации резко обострило конкурентную борьбу. Последние две причины в максимальной степени отразились на экономических отношениях в различных сферах коммерческой деятельности, в том числе в банковском секторе экономики.
Клиенты стали не просто требовательными, но и грамотными. Кроме того, если десять лет назад производители "боролись за клиентов", то сегодня все успешные организации констатируют, что им приходиться "бороться не просто за клиентов, а уже за каждого клиента". Мы об этом говорили, когда рассматривали стратегию развития ИТ. Так, например, если раньше для банков основной интерес представляли крупные корпоративные клиенты, то сегодня идет борьба даже за самое маленькое предприятие с ничтожными оборотами и несколькими работниками. А за рубежом ситуация еще в несколько раз жестче. Там давно идет борьба и за таких, казалось бы, недоходных для банка клиентов, как частные лица, пенсионеры и студенты. Естественно, связано это напрямую с перепроизводством и другими следствиями технологической революции.
Другая важная причина, толкающая коммерческие организации на путь постоянных изменений, как мы уже отмечали, - активная конкурентная борьба. Она последние несколько лет активно ведется и в России. На весьма "прозрачном" банковском рынке все действия хорошо заметны, и это еще одна новая реалия, являющаяся следствием технологической революции. Рынки стали прозрачны и открыты, как никогда ранее. В этой ситуации достаточно какому-либо банку совершить ошибку или просто понизить качество предлагаемых услуг, он сразу начинает терять клиентскую базу. В то же время необходимо помнить, что даже высокоразвитому банку необходимо совершенствоваться, так как все положительное в его работе и технологиях достаточно быстро становится известным на рынке и активно внедряется конкурентами. Поэтому, чтобы находиться хотя бы в незначительном отрыве от конкурентов, необходимо постоянное изменение.
Еще одно следствие технологической революции заключается в том, что современные технологии и прежде всего вычислительные машины резко сократили период разработки товаров или услуг, тем самым еще более увеличивая возможность потенциального предложения. Эта причина также делает практически все рынки и сектора экономики более динамичными.
Однако помимо внешних существуют и внутренние причины, вызывающие необходимость постоянных, кардинальных изменений. Как ни странно, для крупных организаций они, может быть, более значимы. Любая организация (особенно крупный банк), даже если в момент своего основания она была построена по самой оптимальной схеме, через некоторое время утрачивает исходную оптимальность, приобретает функциональную и тактическую несогласованность, нелогичность, непрозрачность. Производственные процессы запутываются, происходит отклонение от основных изначальных ориентиров и приоритетов деятельности, ослабевает мотивация и т.п.
И все это может происходить по причинам не столько внешним, сколько внутренним. Этот феномен известен многим практикующим менеджерам. Причины могут варьироваться в зависимости от особенностей организации, но, как правило, они кроются в несовершенстве исполнителей, а именно: в субъективности их восприятия, привыкании к определенным негативным явлениям, сложности применения теоретических принципов к конкретным человеческим отношениям, банальной текучести кадров и приоритете личных интересов.
Все это приводит к постепенной деформации базисных принципов и ориентиров, отходу от оптимальности, нарастанию стихийности развития и в конечном итоге, если так можно выразиться, к "мутации" системы управления и организации в целом.
За рубежом считается, что любая организация не реже какого-либо определенного периода (в зависимости от своих размеров и особенностей - например, раз в семь лет) должна производить на основе детального анализа текущей ситуации полную реорганизацию (реинжиниринг) своей деятельности. Программа таких изменений может включать различные направления преобразований (реструктуризация, построение новой концепции взаимоотношений, мотивации и менеджмента, смена и/или переквалификация части специалистов, стратегическая переориентация, модернизация технологической и информационной базы, реинжиниринг основных и вспомогательных бизнес-процессов, системы управления в соответствии со стратегическими целями и т.д.).
Все вышесказанное объясняет острую необходимость постоянных изменений, актуальность которых в российских условиях еще выше, так как в отличие от зарубежных стран, где все эти глобальные изменения хотя и происходили стремительно, но все-таки не в течение десяти лет, как это было у нас.
Общий подход: теория и практика
Но вывод о необходимости постоянных изменений не является панацеей от возникновения новых и новых проблем. Каким образом сделать так, чтобы необходимые изменения были не только осознаны и теоретически сформулированы менеджментом, но и практически реализованы? Тут скрываются наиболее серьезные трудности.
Очень часто бывает, что какие-то изменения очевидны, более того, уже обсуждены и даже "приняты" руководством, но тем не менее либо внедряются так долго, что теряют актуальность, либо вообще не внедряются. Тому есть разные причины. Во-первых, это консерватизм людей, привычка к текущей ситуации и даже боязнь, нежелание каких-либо изменений. Все это весьма часто встречается именно в крупных организациях. Во-вторых, несоответствие или даже противоположность интересов разных групп людей внутри крупной организации, возникающих из-за нежелания делиться полномочиями, ограничивать свою власть, брать на себя больше ответственности; это также может быть просто страх существенного сокращения численности своего подразделения. Практика показывает, что внедрение чего-то нового в подразделении влечет за собой существенное сокращение. Это одна из самых сложных управленческих задач, однако решать ее все-таки приходится.
С теоретической точки зрения управление изменениями (Change Management) - это отдельный и не менее сложный, чем разработка самих изменений, вопрос. Существует множество разнообразных научных теорий, направленных на решение данной задачи. Одной из наиболее простых и в то же время часто используемых на практике является теория, предложенная американским ученым-психологом Куртом Левином.
Согласно Левину для управления какими-либо изменениями или преобразованиями чрезвычайно важно понимать природу изменений и их восприятие, их отражение в человеческой психике. Несмотря на то что теория Левина возникла в 40-х годах XX века, она до сих пор считается одним из базовых подходов в управлении изменениями. По концепции Левина для правильного внедрения какого-либо изменения необходимо пройти три стадии: "размораживание", "движение" и "замораживание". Основная идея заключается в том, что при создании изменений обязательно необходимы, помимо собственно преобразований, подготовительная стадия и стадия закрепления результатов.
Подготовительная стадия, или "размораживание", ставит своей основной целью сделать текущее положение еще хуже и невыносимее, довести его до абсурда. Таким образом сознательно развивается ощущение необходимости перемен и их неотвратимости у всех заинтересованных лиц. Кроме того, эта стадия предполагает активизацию деятельности по различным направлениям, связанным с объектом изменений, причем без каких-либо определенных целей, кроме как "расшевелить улей". Все это приводит к тому, что объект (коллектив кредитной организации) вступает в стадию психологической готовности к предстоящим изменениям.
Стадия "движения" предполагает проведение всех запланированных изменений и естественное в этих условиях преодоление препятствий. При этом Левин советует относиться к изменениям именно как к "движению". Необходимо соблюдать определенные и известные участникам преобразований правила, четко понимать не только цель движения, но и маршрут, не стараться двигаться чересчур быстро, другими словами, "не превышать скорости".
Последняя и, возможно, наиболее важная стадия - "замораживание" - ставит целью сделать осуществленные изменения необратимыми, то есть закрепить (или "заморозить") их. Эта стадия особенно важна, так как на практике часто даже после успешного осуществления преобразования ситуация постепенно может обращаться вспять. Это связано с тем, что первое время для объекта изменений (человека или группы людей) его предыдущее состояние по-прежнему является более естественным, знакомым, и по нему может возникать своеобразная "ностальгия". Поэтому, чтобы не произошло "плавного отхода назад", новое состояние необходимо зафиксировать, или "заморозить". Это достигается разными способами, к которым можно отнести средства мотивации как психологического, так и материального плана, разъяснение преимуществ текущей ситуации, обеспечение видения перспектив и новых возможностей.
Рассмотрев вопросы снятия психологических противоречий при проведении изменений, необходимо остановиться и на основных практических подходах к решению задачи управления изменениями при проведении преобразований в кредитных организациях. Рассмотрим, каким образом при возникновении проблем в банках решалась на практике задача внедрения изменений.
Первый возможный подход заключается в централизованном и жестком управлении всеми изменениями со стороны высшего руководства. Для этого, например, в банке вводится постоянная штатная единица - заместитель председателя правления по развитию. Очень важен и принципиален для этого подхода именно высокий уровень лица, ответственного за развитие и изменения, так как в процессе внедрения изменений постоянно возникает необходимость решать множество вопросов, и именно бесконечные согласования и обсуждения способны затормозить любой процесс. Вследствие этого человеку, ответственному за процесс развития банка, необходимы существенные полномочия для принятия решений и контроля исполнения, включая доступ к процессу материального стимулирования сотрудников без дополнительных согласований.
При этом никакая текущая работа, кроме управления изменениями и развитием, не должна входить в обязанности такого руководителя, поскольку данная работа требует очень больших усилий и напряжения и практически всегда связана с решением конфликтных ситуаций. Ответственность данного руководителя в этом случае будет полностью распространяться на все преобразования, и если они не будут осуществлены, значит он не справился со своей работой.
Подобного рода руководителю напрямую должны подчиняться некоторые организационные структуры, с помощью которых он сможет осуществлять аналитическую обработку информации, быструю и грамотную подготовку необходимых материалов, описание и моделирование бизнес-процессов с помощью современного инструментария, анализ правовых аспектов нововведений и их экономического эффекта. Такой подход к управлению изменениями достаточно часто встречается в зарубежных банках. В России некоторые кредитные организации стараются его использовать, и на практике он достаточно эффективен.
Второй подход основывается на том, что в большинстве случаев причиной невозможности практического внедрения каких-то изменений является наличие различных интересов у разных групп исполнителей, руководителей или подразделений. Что удобно одним, кажется неудобным и даже опасным другим. Поэтому для проведения преобразований необходимо в первую очередь снять подобные противоречия и противоположность интересов внутри организации (в большей степени это касается крупных организаций).
Этого можно достичь, например, на основе создания межфункциональных групп. В кредитной организации создается (на постоянной основе или под конкретный проект) группа менеджеров и специалистов, участвующих в осуществлении тех или иных банковских процессов. Группа формируется из наиболее авторитетных и творчески мыслящих представителей всех подразделений, которым доверяют остальные сотрудники и которые выступают одновременно экспертами и защитниками интересов своих групп. Руководство банка наделяет эту группу (комитет) достаточно высокими полномочиями по управлению изменениями. Внутри группы вводится система стимулирования ее участников в зависимости не от осуществления их функциональных обязанностей, а от практической реализации проекта, чтобы снять противоречия интересов. Потенциальный финансовый интерес участников должен быть существенно выше их текущих доходов, чтобы компенсировать возможную потерю ими административных позиций, а также чтобы избежать разногласия внутри группы. При этом другие специалисты и менеджеры банка, не входящие в эту группу, весьма сплоченную вследствие единства и сопряженности целей, не смогут существенно ей противодействовать, и необходимые изменения будут достаточно быстро и активно внедряться в практику.
Третий подход заключается в признании банком невозможности или высокой сложности самостоятельного управления изменениями и активном привлечении для решения этой задачи (в рамках конкретных проектов) сторонних организаций, в первую очередь специализированных консалтинговых и технологических компаний. В этом случае часть полномочий по решению оперативных вопросов и контролю ведения проекта передается внешним консультантам.
Такой подход имеет свои положительные стороны. Во-первых, ответственность за реализацию проектов также возлагается на стороннюю организацию, и оплата ее услуг может находиться в полной зависимости от практического внедрения каких-либо изменений. Во-вторых, такие организации имеют практический опыт решения подобных проблем и застрахованы в отличие от банка от типичных ошибок и промахов.
Разумеется, перечень предлагаемых подходов к решению рассматриваемых проблем не является исчерпывающим, тем не менее они дают представление о практически проверенных способах управления изменениями и решении сложной задачи внедрения нововведений, совершенствования технологии и системы функционирования организации в целом.
Рассмотрим, каким образом должно производиться внесение изменений или полная реорганизация какого-либо банковского бизнес-процесса с точки зрения последовательности или порядка работ. Основные этапы можно сформулировать следующим образом:
- определение объектов изменений и их "размораживание";
- документирование текущей технологии работы и классификация бизнес-процессов;
- выработка критериев оптимизации и определение ограничивающих условий;
- анализ текущей технологии работы;
- выработка, согласование и документирование новой технологии;
- внедрение изменений;
- контроль эффективности осуществленных преобразований;
- корректировка и закрепление изменений. Теперь рассмотрим детально каждый из этих этапов.
Определение объектов изменений и их "размораживание"
Сначала следует выявить первостепенные объекты изменений. Необходимо в первую очередь браться за те направления преобразований, которые могут дать наибольший экономический эффект. С другой стороны, выбор первого объекта должен определяться наличием достаточно высоких шансов на успех, чтобы не выработалось устойчивое противодействие к преобразованиям в организации... И самое главное - не браться за все сразу. Это, как известно, приводит к тому, что не будет сделано ничего.
Также необходимо помнить о наличии подготовительной стадии (о которой говорилось выше, когда мы рассматривали теорию управления изменениями Левина).
Помимо этого, в рамках подготовительной стадии целесообразно заранее определить еще один момент. Учитывая особенности работ по реорганизации, необходимо заранее определить нормы защиты информации, которые будут способствовать свободному и беспрепятственному общению сотрудников организации с группой, осуществляющей изменения. Это необходимая мера, поскольку по необъяснимым причинам многие сотрудники слишком беспокоятся за сохранность и неразглашение информации, не являющейся конфиденциальной.
На подготовительной стадии также необходимо решить вопрос о финансировании работ по исследованию и подготовке к преобразованиям, так как они для своего выполнения потребуют определенных ресурсов, людских и денежных, потому что, даже если организация и не использует привлеченных специалистов, она обязательно должна разработать и внедрить систему дополнительной мотивации и поощрения сотрудников, непосредственно работающих над изменениями.
Документирование текущей технологии
Прежде чем начать основную работу по преобразованиям, следует тщательно изучить положение дел и детально описать процесс "как есть". Такое описание необходимо по многим причинам. Оно будет служить информационной базой для анализа и выработки преобразований, станет источником информации для экспертов, не знакомых с деталями технологии работы организации. Опираясь на данное описание, можно будет восстановить прежнюю практику работы в случае неудачных изменений. Таким образом, описание процесса "как есть" будет носителем знания и реальной практики работы и тем самым сможет защитить организацию.
Но для всех этих целей необходимо, чтобы описание было крайне точным и детальным. И здесь появляется проблема номер один при моделировании технологии работы - противоречие между требуемой детальностью описания и экономической эффективностью этого процесса. Совершенно очевидно, что чем точнее и детальнее описание, тем больше оно требует усилий, времени, ресурсов и, следовательно, существенно дороже. Практика показывает, что затраты на такое моделирование могут находиться в диапазоне от нескольких тысяч до сотен тысяч долларов. Поэтому необходимо находить компромисс, не забывая, что само по себе моделирование деятельности, без связи с преобразованиями, не имеет практически никакой стоимости.
Большинством экспертов признается, что подобное описание целесообразно осуществлять в графическом виде, например в виде SADT-диаграмм (вопросы методологии будут рассмотрены отдельно) с использованием современного программного инструментария в виде CASE-средств. Можно использовать как статические, так и динамические средства моделирования бизнес-процессов, в том числе основанные на других методологиях и стандартах. Выбор их следует осуществлять, исходя из необходимого уровня наглядности схем и предполагаемых сроков разработки таких схем, так как более сложные и наглядные средства моделирования бизнес-процессов подразумевают более сложный и дорогой процесс их оформления. В любом случае самые простые средства моделирования настолько доступны, что можно настоятельно рекомендовать не использовать собственные или недостаточно известные стандарты.
Цель такой работы заключается в создании там, где это необходимо, графического и текстового описания рассматриваемых процессов для дальнейших анализа, контроля и выработки рекомендаций по реорганизации.
Сбор требуемой информации осуществляется на основании регламентирующих документов банка, анкетирования и информации, полученной от сотрудников банка в результате личных бесед. Круг лиц, проводящих опрос, в зависимости от выбранной схемы управления изменениями может состоять из представителей специализированного подразделения, межфункциональной группы или внешних консультантов.
Опросить целесообразно всех сотрудников банка, кроме работников служб охраны, хозяйственного и технического обеспечения, водителей и секретарей. Категорически не рекомендуется опираться на информацию только руководителей подразделений, так как на практике они почти всегда стремятся приукрасить ситуацию и будут рассказывать не о том, как они работают, а о том, как должны или хотят работать. Другой интересный феномен, связанный со сбором информации по технологии работы, - достаточно высокая степень некорректности информации. Опять же практика показывает, что и рядовые исполнители очень часто склонны к искажению информации или ее неточной передаче. Поэтому все собранные данные необходимо тщательно проверять, сопоставляя информацию из различных источников или наблюдая непосредственно за работой специалистов.
Собранная информация поступает на обработку, которая включает следующие этапы:
* создание общей структурной модели банка (по подразделениям), а также модели предлагаемых услуг и обеспечивающих процессов в банке. Глубина данных моделей - сотрудник банка (главный бухгалтер, операционный работник отдела и т.д.) и услуга или процесс банка (расчетно-кассовое обслуживание, уплата налогов). Формулировка миссии, целей, задач и выполняемых функций подразделений банка;
* классификация и описание целей и задач бизнес-процессов, примеры которых приводились выше;
* описание и моделирование бизнес-процессов, определенных в предыдущем этапе. Глубина моделей - операции, выполняемые сотрудниками, документы и состояния документов (заполнить договор, подписать документ, расходный ордер, подтвержденный расходный ордер);
* обсуждение полноты и правильности построенной модели. Корректировка модели;
* разработка дополнительных аналитических документов или описаний (в зависимости от необходимости).
Далее мы рассмотрим, как формируются документы, необходимые для разработки программного обеспечения: функциональные и технические задания и спецификации (многие из преобразований требуют изменений или полной замены информационных систем организации).
Самым недорогим и в то же время достаточно эффективным для преобразований на уровне средних по размеру организаций является построение бизнес-моделей в форме блок-схем в соответствии со стандартом IDEF0 с использованием, например, программного продукта BPWIN*(6), вид интерфейса которого изображен на рис. 15.
"Рис. 15. Интерфейс программного продукта BPWIN"
Дополнительные описания являются приложениями к соответствующим схемам и включаются в файл модели в формате BPWIN, а в случае больших объемов представляются в формате документов MS WORD. При необходимости (и после предварительного согласования) можно дополнить бизнес-модель организации документами, выполненными в других форматах.
В построенной модели для среднего банка могут рассматриваться около 15-20 бизнес-процессов. Общий объем документации, описывающей технологию работы банка, - от 350 до 1000 страниц диаграмм и текста.
Критерии оптимизации и ограничивающие условия
Прежде чем приступить к анализу текущей ситуации и преобразованиям, необходимо четко обозначить критерии оптимизации и произвести ранжирование с точки зрения их значимости. Имеет смысл установить для каждого из критериев весовой коэффициент. Критерии зависят от текущего состояния кредитной организации и стратегических приоритетов в ее развитии. Базовыми критериями к разработке оптимизированной модели являются:
- снижение временных затрат на реализацию бизнес-процессов организации или выполнение отдельных операций;
- снижение стоимости предоставляемых услуг и обслуживающих процессов;
- повышение контролируемости деятельности организации на всех уровнях;
- масштабируемость или наращиваемость технологии и ее гибкость на предмет организации новых услуг и изменение под воздействием внешних факторов (законодательство или экономические обстоятельства);
- изменение соотношения между прямыми и косвенными затратами на реализацию бизнес-процессов организации;
- соответствие предлагаемых решений текущему законодательству и регламентирующим документам;
- повышение качества обслуживания клиентов;
- расширение спектра или увеличение объема операций.
Те или иные критерии для различных банков имеют разное значение. Так, например, сокращение расходов для некоторых из них может быть не так актуально, как увеличение скорости обслуживания.
Анализ текущей технологии работы
После того как бизнес-процесс детально исследован и "зарисован", определены объекты и цели или критерии оптимизации, естественно, должна наступить стадия его анализа и выработки основных направлений концепции его реорганизации. В рамках данного блока могут существовать следующие этапы:
* выявление и анализ операций, не добавляющих стоимости с точки зрения клиента;
* анализ данных с целью выявления однотипных операций в различных процессах, оценка возможности их объединения или исключения;
* анализ возможного видоизменения процессов. Рассматриваются варианты изменения документопотоков исходя из регламентированных условий. Строятся альтернативные модели бизнес-процессов или их отдельные составляющие в тех же стандартах, что и основная модель. Производится их описание, описание необходимых изменений и затрат на переход;
* поиск путей автоматизации отдельных операций. Рассматривается возможность использования компьютерных средств для автоматизации операций, сокращения трудозатрат исполнителей, упрощения операции. Производится оценка затрат и ожидаемого эффекта. Данный этап проводится совместно со службами, ответственными за автоматизацию;
* оценка стоимости каждой операции в масштабах банка. Оценочная стоимость операции включается в ее описание. Оценку операции можно проводить по следующим параметрам: длительность выполнения, количество и периодичность, ежедневные затраты ресурсов (переменные издержки), постоянные издержки, общие материальные затраты;
* анализ сложных операций с целью их разукрупнения и упрощения;
* анализ неоказываемых услуг и возможности предоставления их клиентам. Оценка действий, необходимых для этого, и ожидаемый экономический и маркетинговый эффект;
* сравнительный анализ текущих услуг и практики их осуществления в других банках с целью возможного повышения качества обслуживания и корректировки тарифной политики.
Направления анализа выбираются в зависимости от критериев оптимизации и объекта изменений.
Выработка, согласование и документирование новой технологии
Полученные идеи и результаты первичного обследования являются основой разработки новой технологии. Она осуществляется в несколько стадий.
Вначале определяется концепция потенциальных изменений. Предложения, поступившие в ходе предыдущих стадий, тщательно обсуждаются и оцениваются с точки зрения эффективности их внедрения. Поиск такой концепции - один из сложнейших моментов реинжиниринга, так как является во многом творческой работой. Отчасти поэтому, отчасти потому, что этому вопросу посвящено достаточно публикаций и внимания, в том числе со стороны прародителей теории реинжиниринга, мы не будем уделять ему отдельное внимание.
После выработки и согласования со всеми заинтересованными сторонами и высшим руководством концепции преобразований необходимо приступить к разработке новой технологии или технологической схемы "Как должно быть", описывающей все детали будущей технологии. Инструментальные средства разработки обеих схем "Как есть" и "Как должно быть" должны быть идентичны. Необходимость такого описания связана с невозможностью внедрения чего-то абстрактного, необходимостью проведения переобучения специалистов и т.д.
На основании концептуальной модели определяется порядок взаимодействия между подразделениями. Проводится наложение бизнес-процессов предоставления услуг на предлагаемую схему работы. Определяются регламентирующие документы и нормативные акты, управляющие рассматриваемыми процессами.
Далее производится заключительная детализация модели до элементарных бизнес-операций и технологических решений по их реализации. Параллельно производится корректировка модели в соответствии с возможностями ее реализации и техническими возможностями.
Модель "Как должно быть" также проходит несколько стадий согласований и после этого подлежит утверждению высшим руководством банка.
После описания перспективной технологии, ее корректировки и окончательного утверждения во всех деталях необходимо разработать детальный план внедрения новой технологии с распределением сроков, контрольных точек и ответственных лиц. Такой план может содержать следующие пункты:
* разработка новых должностных инструкций в соответствии с измененными обязанностями исполнителей;
* корректировка учетной политики банка, других внутренних регламентов;
* обучение сотрудников новой технологии;
* прием экзаменов по результатам обучения;
* разработка или настройка программного обеспечения и т.д.;
* запуск новой технологии в опытную эксплуатацию;
* переход на полное промышленное использование новой технологии.
Все эти процедуры должны быть по возможности распараллелены и сопряжены по срокам для меньшей затраты времени на реализацию проекта в целом. Для представления сложных громоздких проектов и осуществления контроля за ними удобно использовать современные инструментальные средства управления проектами.
Достаточно простым примером такого средства может служить программный продут компании Microsoft - MS Project. Этот продукт позволяет автоматизировать распределение ресурсов, контроль выполнения отдельных этапов проекта и связанных задач, общее планирование. Он обладает возможностями планирования и распределения людских ресурсов, мониторинга нагрузок, построения сетевых графиков и Гант-диаграмм, гибкой системой отчетных форм, а также многими другими возможностями. Данный программный продукт в конечном счете облегчает непростую задачу управления проектами с десятками и даже сотнями подзадач, большинство из которых связаны различным образом с другими работами и большим количеством исполнителей. Внешний вид интерфейса данного программного продукта представлен на рис. 16.
"Рис. 16. Вид интерфейса программного продукта Microsoft Project"
He менее важно заранее составить и утвердить бюджет преобразований, в котором будут запланированы все расходы, связанные с реализацией плана реинжиниринга. С учетом того что подавляющее число подобных проектов не укладываются в первоначальный бюджет и испытывают нехватку ресурсов, необходимо заранее на стадии бюджетного планирования заложить специальный резерв в размере 20-25% для покрытия возможных перерасходов.
Контроль эффективности осуществленных преобразований
После начала полного использования новой технологии необходимо произвести оценку эффективности проделанных изменений. При этом, если реальный эффект существенно ниже запланированного, не стоит расстраиваться, так как эта ситуация достаточно типична. Даже если после контрольного анализа осуществленных преобразований окажется, что эффективность их крайне низка или даже стремится к нулю, то есть только окупаются затраты, - это уже хорошо, и такие преобразования должны быть признаны положительными, и их имеет смысл продолжать.
Не стоит при этом забывать о таких следствиях, которые невозможно посчитать в денежном выражении, но которые приносят важные стратегические выгоды. Речь идет об общей активизации деятельности организации, создании у работников и менеджмента ощущения перспективы, дополнительной мотивации, росте интереса к организации со стороны и т.д.
Корректировка и закрепление изменений
На основании данных по реальной эффективности, а также результатов промышленной эксплуатации бывает необходимо осуществить корректировки в деятельности или внедренной технологии. Такие корректировки представляют собой незначительные изменения и возникают вследствие того, что решить все вопросы сразу практически невозможно. Относительно закрепления, или "замораживания", модифицированного процесса уже говорилось выше.
Рассмотрев общие вопросы управления изменениями, настало время вернуться к области информационных технологий и рассмотреть организацию проектной работы, которая, как мы уже отмечали, является логичным продолжением проектов преобразований внутри организации и своей главной целью имеет практическую реализацию механизмов развития бизнеса.
Сразу стоит оговориться, что практику проектной работы мы будем рассматривать на основе проекта замены основной информационной системы банка, как и в первой части книги, где мы уже рассматривали работу по подбору решений на этом же примере. Это связано с тем, что это направление является одним из самых объемных и сложных в ИТ. Но все сказанное ниже будет актуально и для других ИТ-проектов, таких, как развитие интернет-услуг, замена компьютерного оборудования, автоматизация новых филиалов и т.п.
Иногда кажется, что не существует причины, по которой бы организация, имеющая уверенно работающие структуры, стабильную, удовлетворяющую текущим требованиям информационную систему, решилась бы на дорогостоящий проект замены своей информационной базы. Более того, основная часть сотрудников и руководства полагает, что, купив и успешно внедрив у себя однажды то или иное информационное решение, организация навсегда закрыла для себя эту проблему.
Но жизнь опровергает подобное заблуждение. Независимо от типа организации, программного и аппаратного обеспечения, квалификации сотрудников каждый раз повторяется один и тот же сценарий жизни программного приложения. Он длится в среднем 10-15 лет, а при стремительном изменении внешней среды, как это было в последние годы у нас, - 5-7 лет. В течение этого времени программное обеспечение многократно дорабатывается, адаптируясь к новым условиям. Появляется большое количество различных дополнительных решений, реализованных вне рамок системы. При этом решения разрабатываются различными людьми, при полном отсутствии каких-либо стандартов и документации. Потом возникает необходимость установления связей между этими доработками, и количество проблем, требующих решения, возрастает многократно, становясь нерешаемыми.
В результате возникает ситуация, когда небольшое ядро, некогда являвшееся современной и перспективной системой, обрастает неконтролируемым множеством утилит и заплаток. Простое увольнение одного из программистов (средний срок работы программиста в кредитной организации 3-5 лет) приводит к полной переработке целой области информационных задач. Надежность, защищенность подобной системы не удовлетворяет никаким требованиям. И отсутствие проблем со службой безопасности объясняется только тем, что в России службы безопасности очень редко занимаются анализом программного обеспечения в банке. Любое изменение в правилах учета и обработки информации все сложнее реализуется в установленные сроки. Даже если компания-разработчик своевременно предоставляет все доработки, служба автоматизации банка не успевает своевременно адаптировать свои решения к новым условиям.
Попытка решить данную задачу приводит к тому, что менеджеры организации начинают обращать внимание на новые разработки, появляющиеся на рынке, и после очередной проблемы с устаревшей информационной системой принимают решения о покупке новой, которая, по их мнению, снимет большую часть проблем.
Однако выделенные деньги и поддержка руководства не гарантируют того, что проект будет удачным. Он может быть вообще нереализован. По данным ряда зарубежных консалтинговых агентств, около 20% проектов не внедряются. Хотя, если проект будет реализован, скорее всего затраты на него будут существенно выше ожидаемых. По тем же данным, только 16% проектов реализуются в соответствии с первоначальными планами, а затраты на реализацию остальных в среднем в 1,8 раза выше утвержденных бюджетом.
Рассмотрим, какие шаги придется выполнить организации, чтобы минимизировать потери и увеличить шанс успешного завершения проекта. Мы уже останавливались на особенностях проектной работы в самой первой главе, где проектный подход рассматривался как один из ключевых подходов к организации ИТ-службы банка. Но настало время остановиться на этом и рассмотреть отличия проектной и традиционной форм организации работы. Прежде всего нам необходимо определиться с тем, что же такое проект. Мы будем опираться на широко распространенную за рубежом методику управления проектами РМВОК 2000.
Итак, как правило, проекты направлены на выполнение каких-либо вполне определенных задач, связанных с достижением стратегических целей организации. Это происходит потому, что стратегические цели не могут быть достигнуты посредством текущей деятельности, они требуют создания изменений, а средство создания изменений - это проект.
Проекты обычно связаны с новой, уникальной и не повторяющейся или редко повторяющейся работой в отличие от обычной деятельности, которая носит регулярный характер. Поэтому они всегда носят временный характер, ограничены четкими временными раками, операционная же работа является преимущественно постоянной.
Согласно упомянутой выше методике проект - это любая деятельность, ограниченная во времени и направленная на создание уникального нового продукта, услуги или на достижение другой цели. Деятельность, ограниченная во времени, означает, что каждый проект имеет четко обозначенные начало и конец. Проекты осуществляются на всех уровнях организации, в них могут участвовать от нескольких человек до сотен людей.
Примеры проектов:
* разработка новой услуги;
* внутренние организационные изменения;
* реинжиниринг бизнес-процессов;
* разработка и внедрение новой информационной системы;
* внедрение новой бизнес-практики или процесса;
* развитие филиальной сети;
* техническое перевооружение;
* создание позитивного рыночного имиджа.
Общим между проектной и традиционной операционной организацией работ является то, что они выполняться людьми, используют ограниченные ресурсы, планируются и контролируются менеджментом.
Первым шагом любого проект является определение его истинной цели. Необходимо, чтобы каждый участник четко понимал, почему организация вкладывает в проект огромные деньги вместо того, чтобы потратить их на зарплату или выплаты акционерам, какие преимущества по отношению к текущему состоянию он получит по завершению проекта. Только в этом случае участники проекта будут выступать единой командой, и шанс на его успешную реализацию существенно возрастет.
Следующим шагом является определение области проекта. Четкое ограничение рабочей области позволит существенно сократить время на обсуждение и согласование проекта.
После того как определены цель и область проекта, можно перейти к более детальной его проработке и описать условия выполнения. Результатом этого этапа (для нашего примера - замены информационной системы) должны стать ответы на следующие вопросы:
* Какой видится идеальная система? В данном ответе необходимо собрать описания идеальной системы от различных подразделений и определить набор параметров, которым она должна соответствовать.
* Какие параметры системы критичны и их значения? В продолжение предыдущего вопроса необходимо помимо идеальных значений определить минимально допустимые параметры.
* На каком ядре должна базироваться система? Ответ на этот вопрос может дать служба автоматизации на основе имеющегося опыта, наличии системных специалистов и уже имеющихся программно-аппаратных решений. Следует помнить, что, например, смена системы управления базами данных может стоить столько же, сколько и весь остальной проект.
* Каков общий бюджет проекта и каковы максимально допустимые затраты? Это разные величины, определяемые оптимистичным и пессимистичным прогнозами. Различаться на практике, исходя из предоставленных ранее данных, они могут в среднем в 2 раза, а иногда и более. При этом рекомендуется сначала определить максимально допустимую сумму и после этого переходить к сумме бюджета.
Результатом первичного анализа должно быть повторное решение о начале проекта. Учитывая, что первичный анализ не приводит к существенным затратам, принятие решения о временном отказе от проекта не будет психологической проблемой. При принятии повторного решения рекомендуется ответить на все те вопросы, которые уже рассматривались нами в главе "Выбор решений".
Возможно, обдумав все проблемы, которые возникнут при проекте, руководство банка примет решение повременить с его началом. Но если решение не изменилось, то начинается следующий этап.
Для того чтобы решить задачи, направленные на достижение цели проекта, необходимо создать команду проекта под управлением менеджера проекта. При этом речь идет именно о команде со всеми ее признаками: у всех одна цель, хотя каждый имеет свои задачи, все принимают участие в решении важных вопросов, бюрократия сокращена до абсолютного минимума, все подчинено достижению цели, любые поощрения даются всем участникам проекта и только за достижение цели, неформальным лидером команды является самый опытный в решении текущего вопроса, члены команды консультируют друг друга.
Данный подход позволит консолидировать усилия и знания всех участников проекта. К сожалению, в большом количестве организаций объединить сотрудников подобным образом достаточно сложно. Часто различие в статусе подразделений настолько велико, что добиться полного сотрудничества кажется невозможным. Но тем не менее это необходимо.
Преодолеть это можно путем повышения статуса менеджера проекта. Хорошо, если его ранг будет уровня заместителя председателя банка. В этом случае различия между рядовыми участниками не будут казаться столь значительными, чтобы мешать работе. Для иллюстрации рассмотрим два примера.
Первый вариант. Руководитель проекта - начальник отдела автоматизации. Участники команды: сотрудник бухгалтерии (не самый опытный, поскольку самый опытный - главный бухгалтер - не может подчиняться начальнику отдела по статусу), сотрудники отдела автоматизации, казначей (человек, отвечающий за расходы), сотрудник фронт-офиса (тоже не руководитель). При такой организации в проектной группе образуются отношения, изображенные на рис. 17.
Второй вариант. Руководитель проекта - вице-президент банка. Участники команды: главный бухгалтер, начальник отдела автоматизации, казначей (человек, отвечающий за расходы), руководитель фронт-офиса. Отношения в проектной группе при такой организации изображены на рис. 18.
Как видно из схем, если руководитель проекта по статусу стоит выше всех остальных участников команды, имеющийся человеческий потенциал организации используется максимально эффективно. Это приводит к решению большей части задач с минимальным объемом затрат или совсем без них.
"Рис. 17. Схема взаимодействия при руководстве проектом (вариант 1)"
Стоит оговориться, что менеджер проекта может обладать высоким статусом, достаточным для решения всех задач, и не являясь членом правления организации. Так, он может иметь этот статус благодаря своим знаниям и опыту, то есть быть авторитетным экспертом организации или приглашенным со стороны менеджером. Причем этот последний вариант интересен тем, что при этом достигается очень важная составляющая - менеджер является независимым.
Постоянные работники организации слишком подвержены внутренним политическим и социальным отношениям, чтобы быть беспристрастными и профессиональными в полном объеме. Поэтому иногда их действия сложно объяснить. Они могут знать, что и как нужно сделать, но по определенным личным причинам не хотеть этого. Так, часто из-за боязни обнародования неудачи внутренние менеджеры стремятся затягивать проекты на годы, при этом обстоятельно аргументируя свою позицию, прикрываясь нуждами пользователей и необходимостью сделать все в лучшем виде.
"Рис. 18. Схема взаимодействия при руководстве проектом (вариантом 2)"
Особенно стоит обратить внимание на передачу ответственности за проектные затраты казначею. Вариантом такого решения может быть установка лимита затрат на проект с последующим премированием частью сэкономленных денег всех участников проекта. Другой приемлемый вариант - сосредоточение всех финансовых вопросов в руках менеджера проекта. В обоих случаях казначей будет выполнять также роль контролера всех затрат и роль аналитика, их оптимизирующего.
Несмотря на то что вклад руководителя проекта огромен, это ни в коем случае не умаляет роли самой команды. И здесь необходимо отметить несколько моментов. Команда должна подбираться исходя из социальной совместимости ее членов. Плюс к этому участники проекта должны уметь и любить работать в команде. Это умение может значить больше, чем собственный профессионализм, так как польза от задач, выполненных большим профессионалом-одиночкой, меньше, чем потенциальный вред для проекта от разрозненности, несогласованности, отсутствия единого подхода и тяги к нововведениям и изысканиям лучшего решения. Следующий важный аспект подбора команды состоит в том, чтобы оптимально подобрать команду единомышленников, которые при этом будут обладать максимально различными знаниями и умениями. Это связано с тем, что (в нашем примере в процессе смены информационной системы банка) во время реализации проекта всегда будут возникать сложные задачи из смежных областей, и тогда наличие в команде людей с разными знаниями и возможностями позволит решать максимально широкий объем задач без потери времени на поиск нужного специалиста или совета со стороны.
Отдельной темой является наличие времени у участников проекта для его выполнения. Любая деятельность во внерабочее время связана с дополнительными затратами, прямыми или косвенными. Грамотный руководитель проекта сведет такие работы к минимуму или откажется от них вовсе. Хорошим инструментом в поиске свободного времени является поденный месячный график выполняемых задач в течение месяца, а также почасовой график выполняемых задач за день (табл. 14). Для большинства специалистов кредитной организации данные графики неравномерны: там есть и пики, и периоды затишья, которые и являются временным резервом проекта. В общем использование резерва является бесплатным для организации. Иногда следует выполнить ряд работ, как правило, связанных с автоматизацией бизнес-процессов, для увеличения свободного рабочего времени. Автоматизация каких работ дает наибольший эффект, видно из построенных временных графиков (рис. 19).
В любом случае контроль за выполняемыми работами и за загруженностью участников проекта является одной из основных задач руководителя проекта, который должен стремиться к максимально оптимальному распределению задач исходя из особенностей каждого работника, плана проекта и их критичности.
Пример таблицы ежедневной занятости специалистов
┌────────────┬───────────┬──────────┬────────────┬────────────┬────────────┬─────────┬────────┬────────┐
│ Сотрудник │ 9-10 │ 10-11 │ 11-12 │ 12-13 │ 14-15 │ 15-16 │ 16-17 │ 17-18 │
├────────────┼───────────┼──────────┴────────────┴────────────┼────────────┼─────────┴────────┴────────┤
│Специалист │Ожидание │Обслуживание клиентов │Обработка │Ожидание │
│операционно-│(30 мин).│ │документов. │ │
│го зала │Подготовка │ │Контроль и│ │
│ │выписок │ │подготовка к│ │
│ │клиенту │ │отправке │ │
├────────────┼───────────┼──────────┬────────────┬────────────┼────────────┼─────────┬─────────────────┤
│Экономист │Ожидание │Оформление│Формирование│Оформление │Ожидание │Контроль │Ожидание │
│бухгалтерии │ │входящих │документов и│собственных │ │отправки │ │
│ │ │платежей │отчетов │платежей │ │платежей │ │
│ │ │ │закрытия дня│банка │ │ │ │
├────────────┼───────────┼──────────┼────────────┼────────────┴────────────┼─────────┼─────────────────┤
│Специалист │Прием │Ожидание │Закрытие дня│Ожидание │Отправка │Ожидание │
│отдела │информации │ │в АБС │ │платежей │ │
│автоматиза- │из РКЦ.│ │ │ │ │ │
│ции │Печать │ │ │ │ │ │
│ │выписок по│ │ │ │ │ │
│ │счетам │ │ │ │ │ │
└────────────┴───────────┴──────────┴────────────┴─────────────────────────┴─────────┴─────────────────┘
"Рис. 19. Пример графика ежедневной занятости специалиста"
Обычно необходимость предпроектного обследования не вызывает сомнения. Если компания-разработчик объявляет его частью работ по внедрению, то отказать ей в этом невозможно, в противном случае с разработчика будет снята вся ответственность за возникающие проблемы. Если же для помощи приглашены сторонние консультанты, то предпроектное обследование и разработка на их основе перспективной схемы работы организации, а также плана перехода являются объектом их работы.
Однако результаты предпроектного обследования могут существенно различаться в зависимости от того, кто и по каким методикам его проводит. Результатами наиболее полного предпроектного обследования должны быть следующие документы:
* описание текущей деятельности организации и информационной системы. Данное описание становится более наглядным и полезным, если выполнено в графическом формате с текстовыми пояснительными записками;
* перечень документов, участвующих в документообороте, их состояние и печатные формы;
* альбом отчетности, формируемой в организации;
* перспективная модель организации после реструктуризации информационной системы, включая оптимизированную систему документооборота. Также необходимо провести полную экономическую оценку проекта;
* подробный план перехода от текущей модели к перспективной с указанием ресурсов, сроков и исполнителей;
* список доработок информационной системы, утвержденный к внедрению.
Учитывая большой объем предстоящих работ и необходимость проверенных методик для проведения подобного обследования, наиболее логично поручить их либо консалтинговым компаниям, либо специализированному подразделению компании-разработчика.
В ряде случаев можно обойтись сокращенным предпроектным обследованием. Это так называемая двухшаговая реализация проекта. Первый шаг - простая смена ядра системы без расширения функционала и оптимизации документооборота, второй шаг - реализация новых требований на уже работающем новом ядре. Данный подход более стабилен и снижает угрозу работоспособности организации в целом, однако требует большего времени. В этом случае в качестве предпроектного обследования достаточно описания текущего функционала информационной системы. Обследование может быть выполнено либо сотрудниками компании-разработчика, либо сотрудниками кредитной организации.
Несмотря на то что предпроектное обследование требует определенных финансовых затрат, по его результатам рекомендуется сделать дополнительное подтверждение решения о начале реализации проекта с учетом нового понимания объема работ, скорректированного бюджета и ожидаемого эффекта. Обоснованный отказ от проекта на данном этапе будет понят как акционерами, так и высшем руководством. Отказ от проекта на последующих этапах будет означать его провал и, как следствие, санкции для менеджеров и исполнителей.
Одним из важнейших результатов предпроектного обследования, независимо от выбранного сценария, должен стать план проекта, который настолько важен, что ему будет посвящена отдельная глава.
План работ строится на основе согласованного сторонами списка задач. Поэтому, прежде чем составлять план, они должны быть подготовлены. Обычно это происходит на той же стадии предпроектного обследования. Естественно, учесть все аспекты еще только начатых работ, их глубину и реальную трудоемкость невозможно, но тем не менее план проекта в первом приближении может и должен быть составлен именно на этой стадии. Впоследствии он будет расширяться, детализироваться, возможно, пересматриваться, но это не отрицает необходимости его наличия и согласования с самого начала проекта.
При составлении плана работ почти все участники проекта стремятся, чтобы их участие было как можно меньше. Исключением могут являться некоторые сотрудники отдела автоматизации, которые хотят, чтобы работа была как можно более интересной, желательно с решением "сложных" задач, объемной разработкой новых программ и покупкой оборудования. Как правило, эти люди контролируемы, но о них не стоит забывать. С другой стороны, и пользователи, заказчики зачастую пытаются автоматизировать операции, автоматизация которых не имеет никакого смысла, например операцию, которая возникает раз в полгода.
Реалистичность объема проектных задач и сроков - это первый экзамен, который должен успешно сдать менеджер проекта при начале работ и закрепить его в плане проекта. Самое легкое - отвечать на все предложения: "Мы это сделаем и очень скоро", ведь проект только начинается. Но ответственный руководитель проекта должен быть пессимистом, учитывать опыт других проектов и очень реалистично оценивать имеющиеся силы и ресурсы и уметь говорить "нет", аргументируя свою позицию. Менеджер проекта, видя перед собой постоянно основную цель проекта, должен уметь находить компромисс и убеждать все стороны.
Как же может быть сокращен и адекватно оценен объем требований? Основным приемом снижения объемов работ является поиск работающих прототипов. Если требуются новые отчеты при расчете налогов, надо выяснить, нет ли аналогичных отчетов в других областях. Если требуется организация новой услуги, надо посмотреть, как она реализована в других банках. А если ее там нет, то еще раз проанализировать ее необходимость.
Общий алгоритм поиска прототипа заключается в следующем. Сначала идет поиск аналогов решения всей задачи. Если их нет, то формулируется более общая задача и ищутся подобные решения. И так до тех пор, пока не будет найдено ближайшее по смыслу работающее решение. Затем определяются доработки к нему. Например, если нужна система межфилиальных расчетов, за основу можно взять систему расчетов в РКЦ или SWIFT, или систему "банк-клиент". Всегда есть аналогичные системы, доработка которых существенно дешевле и надежнее, чем разработка системы с нуля. Кроме того, если в приведенном примере система расчетов будет создаваться на базе системы "банк-клиент", то побочным эффектом будет расширение предлагаемого клиентам сервиса.
Другой универсальный механизм оценки адекватности требований и оправданности их автоматизации - это финансовая оценка. По каждой потенциальной задаче руководителем проекта может быть сделана оценка требуемого времени специалистов, учтены все необходимые другие ресурсы и в конечном счете получена оценка стоимости выполнения этой отдельной задачи. Она должна быть сравнима со стоимостью поддержки данной операции в "ручном" или полуавтоматическом режиме. Не очень умно автоматизировать получение отчета, затраты на ручное выполнение которого в десятки раз ниже стоимости доработки системы. Окончательное суждение в подобных вопросах должно принадлежать представителям бизнеса.
Рассмотрим теперь технические вопросы составления самого плана проекта. Самая лучшая формула, которой можно при этом руководствоваться, - это "Плохой план проекта сегодня лучше, чем хороший завтра". Многие руководители проектов пишут планы месяцами, они составляют десятки страниц. Но, к сожалению, их никак не могут дописать и согласовать. План может быть объемным, но 2-3-страничный план, особенно на начальных стадиях, не только является допустимым, но и более предпочтительным.
Из того, что обязательно должно быть в плане, - это ключевые точки (обучение, согласование детальных требований, презентация и корректировка прототипа, завершение разработки, начало и конец тестирования, исправление замечаний, начало и окончание пользовательского тестирования, дополнительное обучение, начало опытной эксплуатации, переход на промышленную эксплуатацию) с точным указанием времени их наступления. Также в плане должны найти свое отражение перечень основных задач и их взаимозависимость, распределение задач по этапам, ресурсное обеспечение и ответственные лица. Если все это есть и согласовано со всеми сторонами, то план достигает своей цели.
Ниже представлен пример планов проекта, выполненных в традиционном виде с помощью специального программного продукта MS Project, и более простой вариант плана проекта, подготовленный с использованием MS Excel (рис. 20 и 21).
"Рис. 20. План проекта в виде Гант-диаграммы, подготовленный в MS Project"
Следующий этап - детальная постановка задачи. Корректная постановка задачи - уже повышение вероятности успеха и сокращение затрат на проект на 30-50%. Четкие ответы на вопрос "Что надо?" часто сразу дают ответ на вопрос "Как делать?". Особенностью российских правил учета является тот факт, что изменения в них часто носят весьма глобальный характер, в результате четкого понимания всех изменений на этапе начала проекта нет ни у кого в организации. Для решения этой проблемы используются приемы, которые рассмотрены ниже.
Описание глобальной цели проекта включает ответы на вопросы "Зачем?" как для внешней среды (Зачем ЦБ РФ издал такую инструкцию?), так и самой организации и ее подразделений (Зачем организации реализовывать этот проект?). Вариантов ответов на последний вопрос может быть несколько: "Чтобы организацию не оштрафовали" (самый неудачный ответ), "Данная инструкция позволит снизить операционные риски от совершения операций" и т.д. Анализ ответов позволит не только более точно понимать детали изменений, но и прогнозировать дальнейшие дополнения и исправления.
"Рис. 21. Упрощенный план-график проекта"
Создание единого информационного пространства проекта. В простейшем варианте оно представляет собой директорию, в которой все участники проекта записывают имеющуюся у них информацию и соображения по поводу решаемой задачи. Более сложным вариантом является организация интранет-конференции.
Использование ролевого моделирования процесса подразумевает обыгрывание несколько раз бизнес-процесса всеми его участниками с обязательной регистрацией всех выполняемых действий и пожеланий:
┌────────────────────────┐ ┌─────────────────────────────┐
│Сотрудник бухгалтерии: │ │Сотрудник отдел отчетности: │
│Я регистрирую документ│ │Я формирую отчет группировки│
│данного типа в АБС.│ │платежей по статьям расхода│
│Ввожу следующие поля: │ │за период. В качестве│
│СЧЕТ ПО ДЕБЕТУ, СЧЕТ ПО│ │параметра отчета я должен│
│КРЕДИТУ, СУММУ,│ │определять интервал дат.│
│НАЗНАЧЕНИЕ... │ │Отчет должен иметь следующую│
│ │ │форму: │
│ │ │ │
│Пометка: надо вводить│ │┌────┬─────┬────┬─────┬─────┐│
│еще и статьи расхода....│ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │└────┴─────┴────┴─────┴─────┘│
└────────────────────────┘ └─────────────────────────────┘
Данный прием моделирования позволяет максимально использовать имеющийся человеческий капитал, поскольку каждый участник строит свой бизнес-процесс самостоятельно, а общий контроль осуществляет руководитель и представители других подразделений.
Описанные приемы помогут группе более точно понять и написать техническое и бизнес-задание проекта. В бизнес-задании описываются основные функциональные требования, техническое - отражает более детальную информацию, особенности, включая параметры и подходы к реализации. Иногда они подготавливаются разными людьми, но гораздо чаще представляют единый документ, который готовится одним человеком - аналитиком. Далее мы не будем делать различий между этими документами и понятиями.
Следует помнить, что, если точного задания не получится, придется давать системе, реализующей проект, дополнительную гибкость. Но реализация универсальной, гибкой бизнес-функции требует в несколько раз больше ресурсов на разработку и сопровождение, чем статичное решение.
Кроме того, рекомендуется вести разработку двух заданий, которые условно можно назвать: "Программа-минимум" и "Программа-максимум". В первом варианте нужно описать минимальные изменения в организации по сравнению с текущим положением дел, достаточные для реализации основной цели. Второй документ должен составляться с учетом всех пожеланий и перспектив. Как правило, в конце проекта будет реализован некоторый промежуточный вариант. Имея установленный проект бюджета, группа сначала реализует только самые необходимые требования (на это бюджета, как правило, хватает), а потом либо будет дополнять данное решение новыми возможностями, либо аргументирует прекращение работ и возьмет на себя ответственность за это.
В любом случае при постановке задачи, как и везде, вредны крайности. Многие проекты были загублены чересчур грамотными аналитиками, которые месяцами составляли задания, исчисляемые сотнями страниц. Потом сами же с трудом могли понять, что они имели в виду, настолько запутана и сложна была задача или ее описание. Поверхностность также вредна. Исходя из практического опыта, можно сказать, что ориентирами "золотой середины" могут являться параметры объема работ по подготовке технического задания, представленные в табл. 15.
Ресурсы и объем работ по подготовке технического задания
┌────────────┬────────────────────┬───────────────────┬─────────────────┐
│Размер банка│ Количество │Примерное время для│ Примерный │
│ │ выделенных для │завершения этапа с │ суммарный объем │
│ │ постановки задачи │учетом согласований│ задания в │
│ │ аналитиков │ │ страницах, с │
│ │ │ │ учетом │
│ │ │ │ комментариев │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Небольшой │ 2-3 │ 1-2 месяца │ 100-150 │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Средний │ 4-5 │ 3 месяца │ 200-300 │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Крупный │ 6-8 │ 4-5 месяцев │ 350-500 │
└────────────┴────────────────────┴───────────────────┴─────────────────┘
Вне зависимости от модели организации работы на проекте и степени вовлеченности внешних консультантов в проект с самого начала необходимо организовать регулярное и эффективное взаимодействие проекта с высшим руководством организации. Это позволит облегчить принятие требуемых решений, будет способствовать повышению статуса проекта, явится источником дополнительной мотивации и повышения ответственности участников проекта. Реализация такого взаимодействия обычно происходит в следующих формах.
Проектный комитет - орган управления проекта, который должен состоять из представителей высшего менеджмента организации, бизнес-менеджмента и менеджера проекта. Он должен периодически собираться для принятия и утверждения самых важных решений по ходу проекта. Периодичность зависит от фазы проекта, но в целом это не должно происходить реже, чем раз в месяц. Менеджер проекта докладывает комитету об основных результатах работы, текущем состоянии проекта, основных проблемах, принятых решениях, ситуациях, требующих решения комитета и выходящих за компетенцию менеджера. В процессе заседания комитета ведется протокол, который затем предоставляется всем участникам и заинтересованным лицам и является официальным документом для банка, проекта и подрядчиков.
Спонсорство - важный элемент проекта. Для проекта должен быть назначен спонсор (куратор), лицо из высшего руководства, один из членов проектного комитета, обычно близкий бизнес-подразделениям, который будет более активно взаимодействовать с менеджером проекта для помощи и консультирования. Он должен быть представителем руководства, уполномоченным принимать любые решения, который будет больше всех других высших менеджеров организации в курсе хода проекта и его проблем. Обычно это человек, который выступал инициатором проекта среди руководства или поддерживал его с самого начала.
Периодическая отчетность. Руководитель проекта должен готовить для информирования всех заинтересованных сторон о ходе работ специальные отчетные формы. Периодичность их зависит также от состояния проекта, но в общем должна быть чаще, чем заседания проектного комитета. Может быть рекомендована следующая схема. Если проект испытывает сложности, имеет место срыв сроков, недостаток бюджета и т.п., то отчетность должна предоставляться еженедельно. Если проблемы у проекта есть, но не очень значительные, отчетность составляется раз в две недели. И если у проекта нет каких-либо проблем, способных повлиять на срок, бюджет, то раз в месяц. В отчетах должен быть в удобной форме отражен текущий статус проекта, этап и его фаза, основные ближайшие контрольные точки, выполненный по сравнению с предыдущим отчетом объем работ, достижения проекта за период, основные риски, проблемы, действия по их минимизации и решения, открытые вопросы, прогноз по выполнению сроков и бюджета.
Задачей разработки программного обеспечения является построение систем, отвечающих требованиям бизнеса и обеспечивающих максимум преимуществ от их использования. В то же время эти системы должны создаваться с учетом их дальнейшего сопровождения, требований к производительности и качеству. Организация, осознавая всю важность использования информационных технологий, ставит перед собой цель создать базу для разработки и внедрения программного обеспечения, отвечающего вышеуказанным задачам.
Данная глава описывает основные требования к разработке программного обеспечения как собственными разработчиками, так и с использованием сторонних организаций. Кроме того, в ней определены обязательные этапы при создании и внедрении программных продуктов, требования к документированию каждой стадии и контролю качества продукта. Тестирование и внедрение, являясь составными частями разработки, будут рассмотрены в специально выделенных для этого главах. В настоящей главе мы не будем делать различий между разработкой программного обеспечения, его модификацией, доработкой и настройкой. Мы будем считать, что все перечисленные подходы входят в понятие разработки, являясь методами ее технического осуществления.
Итак, каковы основные участники процесса разработки?
Заказчик - подразделение организации, у которого возникла необходимость в разработке нового или изменении существующего программного обеспечения. Также в качестве заказчика может выступать организация в целом.
Разработчик - проектная команда, сформированная на основе службы ИТ или сторонней организации, непосредственно работающая над разработкой, изменением и внедрением программного обеспечения.
Контролеры - сотрудники организации (кроме непосредственно разработчиков), осуществляющие наблюдение за созданием продукта. Контролерами могут выступать начальники подразделений или назначаемые ими сотрудники подразделения. Если заказчиком является организация, то контролеры назначаются руководством. Для больших проектов, важных для бизнеса, возможно привлечение в качестве контролеров сторонних консультантов.
Аналитики - специалисты в области банковских технологий, участвующие в постановке задачи и консультировании всех сторон в ходе проекта.
Одним из первых важнейших требований является документирование всех этапов процесса разработки программного обеспечения, начиная с постановки первоначальных требований и заканчивая вводом в эксплуатацию и дальнейшим сопровождением. Документы, возникающие в процессе разработки, такие, как спецификации, планы разработки, руководство пользователя, являются неотъемлемой частью программного продукта. Заказчик вместе с программным продуктом должен по возможности получать всю документацию, связанную с разработкой продукта. Документирование процесса разработки ведется с целью облегчения процесса сопровождения, доработки и контроля качества продукта. В случае смены разработчика проектная документация должна обеспечить дальнейшую эффективную работу с программным продуктом.
Качество документации должно отвечать следующим критериям:
* правильность:
- соответствие (трассируемость) требований и спецификаций соответствующей системе, и наоборот;
- последовательность в описании требований, спецификаций и функций;
* полнота:
- использование версий и дат документов для контроля изменений, доступность всех версий документов (в том числе рабочих);
- функциональность системы должна быть максимально полно описана в системных требованиях;
- документация должна предоставлять информацию для всех категорий пользователей, операторов системы и разработчиков;
* удобство и простота использования:
- использование оглавлений, алфавитных указателей, глоссариев и кросс-ссылок;
- логическая последовательность и непротиворечивость в использовании терминологии;
- уместный внешний вид документации (шрифты, формат).
В то же время необходимо, как уже отмечалось, избегать излишней бюрократизации, другими словами - в зависимости от цели проекта набор, состав и объем документов должен меняться.
Применительно к исходным кодам программ, которые по сути являются документацией к системе, также должны во многом выполняться вышеуказанные требования. Исходные коды разработанных для банка систем (как силами собственных программистов, так и сторонними организациями) должны по возможности предоставляться вместе с системой и документацией к ней. Это условие необходимо включать в договора на разработку программного обеспечения и в служебные инструкции разработчиков. Исходные коды должны содержать комментарии в количестве, необходимом для понимания структуры исходного кода и функциональности каждого модуля, подпрограммы или класса. Код программы должен писаться с учетом дальнейшего сопровождения и возможного расширения функциональности системы.
Программный код должен быть отформатирован в едином стиле. В общем случае утвержденные и используемыми всеми разработчиками стандарты кодирования содержат следующие составляющие:
* принципы форматирования программного кода, включая использование структурированного расположения текста и отступов между строками кода для удобства считывания. Комментарии в коде должны давать краткое описание функциональности программ, модулей, классов, методов класса и т.п., а также описывать формат и назначение входных и выходных данных;
* соглашения о стиле программирования должны, в частности, описывать стандарты именования переменных, констант, классов и т.д. Должен применяться общий подход к использованию внутренних переменных, констант и структур данных (таких, как массивы). Все это поможет созданию предсказуемого и легко читаемого кода, с которым было бы несложно работать как на этапе разработки, так и в ходе модификации и дальнейшего сопровождения; приемы написания эффективного кода. Эти правила могут быть связаны с использованием эффективных структур данных и алгоритмов, созданием максимально производительных запросов к базам данных и т.п.
Представители заказчика обязаны принимать участие и контролировать процесс разработки на всех этапах. Должны быть назначены представители заказчика (подразделения организации или выделенные эксперты), отвечающие за разработку, - контролеры. Это могут быть сотрудники банка, знающие в деталях бизнес-процессы, для поддержки которых создается система, сотрудники службы информационных технологий или сторонние консультанты. Для максимальной отдачи от внедрения разрабатываемых систем крайне необходимо тесное взаимодействие с разработчиками.
Ответственность за разработку систем помимо назначенных сотрудников или консультантов несут соответствующие руководители подразделений или организации в целом.
Оценка эффективности разработки
Масштаб и степень следования стандартам разработки программного обеспечения могут зависеть от размера и характера проекта, а также от того, какие инструменты разработки используются. Для небольших, некритичных для бизнеса приложений необходимость строгого следования стандартам может быть не так важна. Однако для больших и чувствительных с точки зрения бизнеса проектов, где велика стоимость разработки и появляются большие риски, необходимы максимальный контроль за процессом разработки и следование стандартам программирования.
В любом случае затраты и усилия, потраченные на разработку, должны соответствовать уровню решаемых с помощью системы проблем. Стоимость проекта должна оцениваться с точки зрения его важности и выгоды от использования разработанной системы.
Целью разработки новых систем и модификации существующих является повышение эффективности бизнес-процессов, поэтому помимо разработки программного обеспечения необходимо параллельно рассмотреть другие варианты мер, влияющих на эффективность организации (дополнительное обучение сотрудников, реорганизация подразделений, незначительное изменение или всеобъемлющий реинжиниринг бизнес-процессов с привлечением сторонних консультантов и т.п.). Эта проблема очень важна, и поэтому она будет детально рассмотрена в рамках главы "Управление изменениями".
Процесс разработки программного обеспечения должен содержать этапы инициации (организации) проекта, оценки проекта, анализа и проектирования, конструирования и внедрения системы.
Этап инициации проекта, с точки зрения разработчика, должен включать подготовку заказчиком требований к новой системе, описание ее функций и структуры, оправдание ее с точки зрения бизнеса и получение одобрения со стороны руководства для того, чтобы приступить к следующим этапам разработки. Если заказчиком выступает подразделение организации, необходимо одобрение руководителя подразделения, если заказчик - организация в целом, то руководителей организации.
Первоначальные требования к системе направляются, как правило, в ИТ-подразделение, которое оценивает факторы, критичные для успеха проекта и его качества. Необходимо выяснить, насколько проект согласуется с общей стратегией банка в области развития бизнеса и использования информационных технологий, приблизительно оценить общие затраты на проект, а также каким образом и кем должен осуществляться контроль над проектом.
Оценка проекта и его согласование были рассмотрены выше, поэтому мы здесь лишь упомянем о них.
В направлении дальнейшей детализации необходимо выбрать несколько вариантов реализации программного обеспечения и точно оценить стоимость каждого варианта, трудности, связанные с его осуществлением, время на осуществление, программные средства и инструменты, необходимые для проекта, исполнителей проекта, а также преимущества каждого варианта. Кроме того, требуется описать недостатки существующей системы и как они будут устранены при внедрении нового программного обеспечения. В итоговую оценку необходимо включить меры по изменению бизнес-процессов и структуры организации, которые сопровождают внедрение системы. Детальную оценку проекта осуществляет ИТ (проектная команда), заказчик выбирает окончательный вариант решения. Итоговый документ должен быть подписан заказчиком и проектным руководством, руководителем ИТ.
Этап анализа и прогнозирования включает в себя разработку проектной документации, в деталях описывающей работу будущей системы, ее структуру, технические и программные средства, необходимые для ее функционирования. Этот этап важен для облегчения дальнейшей работы над системой.
Итогом данного этапа должны явиться одна или несколько спецификаций системы, которые готовятся разработчиком при поддержке заказчика. Мы уже отмечали, что для наших целей не будем различать различные типы спецификаций. Отметим лишь, что вне зависимости от их названия они должны содержать:
* описание бизнеса (бизнес-процессы и функции, которые будут автоматизированы):
- детальное описание существующих бизнес-процессов и каким образом они будут затронуты при внедрении системы;
- детальное описание новых бизнес-процессов, которые будут созданы или получены при изменении существующих;
- описание мер контроля, которые будут внедрены в новой системе;
описание программно-аппаратного обеспечения, необходимого для функционирования системы:
- операционная система(ы), которая будет использоваться;
- сетевая среда, оборудование и протоколы;
- средства разработки новой системы;
- средства защиты информации;
- как новые платформы будут включены в существующую информационную инфраструктуру;
* спецификация функциональности системы:
- общее описание функциональности системы как в повествовательной форме, так и в виде диаграмм;
- разбиение системы на модули;
- соответствие модулей бизнес-требованиям к системе. Должно быть описано, каким требованиям отвечает каждый модуль. Все бизнес-требования должны покрываться модулями системы;
- модель данных, используемая в системе (диаграмма "сущность- связь" или аналогичные). Функциональность, вынесенная в серверную часть системы;
- описание того, каким образом будут реализованы требования к информационной безопасности, производительности и надежности системы;
- детальное описание интерфейсов с другими системами;
- список разрабатываемых программ (включая вспомогательные) и параметры для их запуска;
- список ошибок и предупреждений, генерируемых системой;
- спецификация должна быть четко структурированной и содержать оглавление, алфавитные указатели, глоссарий и список используемых терминов.
Все спецификационные документы подписывает разработчик и предоставляет для ознакомления заказчику.
Написание подробных спецификаций (постановку задачи) можно заменить использованием методики создания прототипов. При этом прогрессивном методе используется итерационный подход. Описание будущей системы производится через согласование интерфейсов пользователя с системой. С будущими пользователями системы обсуждаются и утверждаются экранные формы, соответствующие различным функциям системы. Вместе с внешним видом этих форм описываются соответствующие им входные и выходные данные. Другими словами, время на подготовку документов практически не тратится, пользователь рассказывает, что ему нужно, разработчик создает модель и презентует ее пользователю, который высказывает свои замечания и т.д., пока решение (или по крайней мере его внешний вид) не согласовывается. Выгодой этого подхода являются меньшие сроки разработки системы, следовательно, меньшие затраты на разработку.
Решение об использовании методики создания прототипов принимается до начала этапа анализа и проектирования, на этапе выбора варианта реализации системы. При принятии решения должны быть оценены следующие риски:
* рамки проекта могут быть значительно расширены без формального одобрения, так как пользователи системы могут добавлять "полезные" с их точки зрения функции;
* прототипы описывают только интерфейсы пользователей, и такие вопросы, как информационная безопасность, могут быть упущены на этапе проектирования;
* не для всех компонент системы можно создать прототипы;
* использование прототипов не так детально описывает разрабатываемую систему, как написание спецификаций. Следствием могут явиться трудности с поддержкой и сопровождением в долгосрочной перспективе, а также недостаточный уровень тестирования каждого модуля.
На этапе конструирования формально описанные требования к системе, созданные на стадии анализа и проектирования, преобразуются в рабочую систему. Разработка включает в себя создание структуры программы, кодирование, создание структуры базы данных и тестирование на уровне модулей системы, системы в целом и интерфейсов с внешними приложениями.
Система должна согласовываться с формальными требованиями к ней. В случае внесения существенных изменений в систему, не описанных в проектной документации, эти изменения должны быть согласованы с заказчиком и внесены в спецификации.
Программное обеспечение разрабатывается с использованием структурного подхода, при этом должны соблюдаться ранее установленные стандарты кодирования. Исходные коды содержат комментарии в количестве, необходимом для понимания структуры исходного кода и ее функциональности. Следует максимально снизить риски, возникающие при смене разработчиков.
Программный код должен быть составлен на основе уже упоминавшихся стандартов. Разработчик при этом использует систему контроля версий исходных кодов. При внесении изменений в исходный код описывается, какие изменения и с какой целью вносились.
Разрабатываемое программное обеспечение тщательно тестируется (методика тестирования будет рассмотрена подробно в следующей главе). Должен быть разработан план тестирования, который включает этапы тестирования модулей системы, системы в целом, интерфейсов с внешними программами, интерфейсов пользователя, тестирование систем безопасности и надежности системы. Согласно этому плану необходимо разработать набор тестов, которые помимо покрытия функциональных требований к системе (тестирования по методу "черного ящика") покрывали бы внутреннюю структуру исходного кода (покрытие условных переходов, метод "белого ящика").
Тестовая среда, база данных и исполняемые модули должны быть отделены от рабочей системы. Разработчики не должны иметь доступ к рабочей системе после ее внедрения и запуска.
Результаты тестирования должны быть зафиксированы, в случае обнаружения ошибок они исправляются разработчиком, и это должно быть отображено в отчете по тестированию. Результаты тестирования - найденные ошибки и как они были исправлены - должны быть подписаны разработчиком и предоставлены заказчику.
На этапе конструирования разработчик разрабатывает документацию для пользователей и администраторов системы в электронном и бумажном виде. Документация должна иметь надлежащую структуру, содержание, формат и внешний вид.
Должны быть разработаны программы учебных курсов и соответствующие учебные материалы, которые учитывают специфику всех категорий пользователей и администраторов системы.
В случае необходимости могут быть описаны дополнительные меры, необходимые для внедрения системы. Например, установка нового оборудования, перепланировка используемых помещений, изменения в структуре организации и обязанностях сотрудников, описание необходимых административных процедур и т.д.
На этапе внедрения, особенности которого также будут рассмотрены в отдельной главе, разработанная система должна быть установлена на серверы и рабочие станции, подготовлена и передана заказчику документация, проведено обучение пользователей и администраторов системы. На этой стадии система окончательно принимается заказчиком.
Заказчик должен убедиться, что документация является полной, подготовлена согласно принятым стандартам и покрывает требования к системе. Учебные курсы должны полностью покрывать функциональные возможности системы и отвечать запросам различных групп пользователей и администраторов. Все пользователи и администраторы, перед тем как начать работу с системой, проходят соответствующие курсы.
Заказчику необходимо убедиться, что установка нового программного обеспечения не повлияет на данные уже работающих систем. При переносе данных из старой системы необходимо протестировать, что данные перенесены правильно и полно. Результаты переноса утверждаются заказчиком.
Заказчик составляет план приемки программного обеспечения, разрабатывает набор тестов для проверки функциональности системы и проводит тестирование в соответствии с планом. Кроме того, ему необходимо убедиться в том, что система установлена правильно и предусмотрены все необходимые меры, связанные с защитой информации и надежной работой системы.
Служба поддержки пользователей организуется силами разработчика или на базе сотрудников заказчика. В отношениях между заказчиком и разработчиком должны быть предусмотрены соглашения об уровне обслуживания, на каких условиях будет производиться сопровождение системы, каким образом будут исправляться ошибки, обнаруженные во время эксплуатации системы, а также гарантийные условия.
Документ о завершении внедрения системы подписывают заказчик и разработчик.
Качество и эффективность внедрения напрямую зависят от интенсивности контроля со стороны заказчика. Однако любую внедренную систему можно улучшить с точки зрения эффективности ее функционирования, удобства работы, производительности и надежности. С этой целью по окончании приемки системы можно провести обзор качества разработки и внедрения, в ходе которого выясняются недостатки и упущения в разработанной системе. Этот обзор проводится с помощью сотрудников банка, компании-разработчика или сторонних консультантов. Результатом обзора может явиться отчет о найденных недостатках, содержащий рекомендации по их устранению.
Тестирование представляет собой процесс оценки системы (или компонента системы) ручным или автоматическим способом с целью проверки соответствия указанным требованиям или выявления различий между ожидаемыми и фактическими результатами. Тестирование также подразумевает использование разработанной программы для обнаружения ошибок. Прохождение тестирования не означает, что система больше не содержит дефектов. Тестирование может выявить наличие проблем, а не доказать их отсутствие.
Тестирующий сотрудник не только пытается обнаружить недостатки, но и проверяет программу в работе, оценивает ее надежность, безопасность и безотказность в эксплуатации. Присутствует также экономический аспект. Для более крупных проектов больший объем тестирования обычно выявляет большее количество ошибок. Когда следует прекратить тестирование и какую степень наличия ошибок следует считать приемлемой? Если количество ошибок не превышает определенной допустимой величины, то программное обеспечение может быть квалифицировано как удовлетворяющее требования пользователей и допущено для эксплуатации. Необходимо помнить, что тестирование предполагает, что требования к системе уже сформулированы и не модифицируются.
"Рис. 22. Разработка программного обеспечения"
Стратегия успешного тестирования начинается с процесса его обсуждения на стадии составления спецификаций требований. Тестирование деталей следует проводить на высоком и низком уровне, причем тестирование должно проводиться сначала разработчиками, а затем конечными пользователями. По мере повышения сложности программного обеспечения увеличивается значение эффективного, хорошо спланированного тестирования.
В зависимости от характера и сложности информационного решения банк будет выбирать объем необходимых процедур тестирования. Процесс тестирования может включать все описанные ниже этапы в случае собственного программного обеспечения и некоторые из этих этапов - в случае покупки готового программного обеспечения.
Тестирование "белый ящик" выполняется с целью обнаружения проблем во внутренней структуре программы. Это требует от проверяющего глубокого знания внутренней структуры и, следовательно, не может быть выполнено обычным пользователем. Общая задача такого тестирования - обеспечить проверку каждого шага по алгоритму программы. Основное преимущество всех типов стратегий тестирования "белый ящик": при тестировании принимается во внимание структура всей программы, что облегчает обнаружение ошибок даже в том случае, когда спецификации программного обеспечения недостаточно определенные или неполные.
Тестирование по блокам заключается в проверке блока отдельно от остальной системы. Обычно блок представляет собой функцию или небольшой набор функций (библиотеки, классы), которые выполняются одним программистом. Основная отличительная характеристика блока состоит в том, что он достаточно небольшой по объему для проведения тщательной проверки, которую можно назвать исчерпывающей. Обычно тестирование "белый ящик" проводится разработчиками. Небольшой размер блоков позволяет обеспечить высокий уровень проверки кодов. Таким образом легче обнаружить и устранить ошибки на данном уровне тестирования.
Одним из наиболее сложных аспектов разработки программного обеспечения являются интеграция и тестирование больших подсистем. Интегрированная система часто дает существенные и необъяснимые сбои, которые трудно устранить. Тестирование в таком случае состоит в проверке нескольких блоков, которые образуют модуль или подсистему. Тестирование интегрированной системы в основном направлено на интерфейс между блоками, что должно гарантировать совместимость блоков и их корректную совместную работу.
Тестирование "черный ящик" состоит в поиске отсутствующих или неправильно выполняемых функций с целью оценки, насколько хорошо программа отвечает требованиям. Функциональные тесты обычно подтверждают правильность данных на вводе и выходе. В этом случае пользователь - идеальный проверяющий. Иногда такое тестирование называют пользовательским. Тест функциональности состоит в том, чтобы проверить правильное выполнение отдельных функций системой. Проверяющие проводят тесты, которые, по их мнению, отражают использование системы в будущем, ее функциональных возможностей.
Системный тест представляет собой более полную версию теста на проверку внешней функции, но в максимально приближенных к "боевым" условиям и среде. При системном тестировании техническая платформа должна быть как можно ближе к фактическим условиям эксплуатации, включая такие факторы, как комплектация оборудования, а также объем и сложность базы данных. В ходе воспроизведения будущих условий эксплуатации системы можно точнее протестировать более сложные черты системы (характеристики, безопасность и безотказность). Однако воспроизводить среду пользователя для системного теста слишком дорого, к тому же может не хватить времени на проведение испытания.
Системное тестирование обычно включает в себя тестирование характеристик, которое выявляет время ответа на запрос, использование памяти, оборудования и время выполнения операции. Тестирование в стрессовой ситуации подводит систему к некоторым пределам для оценки ее возможностей и способности справляться с ошибками. Тесты надежности оценивают реакцию системы на ввод данных, проводят подсчет отказов за определенный период времени с целью оценки или подтверждения степени надежности.
Ретроспективное тестирование представляет собой обязательную проверку, выполняемую на модифицированном программном обеспечении, с целью достижения уверенности в том, что изменения в программу внесены правильно и не оказали отрицательного воздействия на другие компоненты системы.
"Приемо-сдаточное испытание" - это проверка готовой системы группой конечных пользователей с целью окончательного подтверждения готовности системы к работе. В этом случае программа пройдет более реальную проверку, чем на этапе системного тестирования, поскольку пользователи имеют лучшее представление о том, как система будет использоваться.
Рассмотрим некоторые типичные ошибки, совершаемые организациями в результате попыток провести эффективное тестирование программного обеспечения. Эти ошибки можно разбить на 4 категории.
1. Неправильное понимание роли тестирования. Назначение тестирования заключается в обнаружении дефектов продукта. В связи с этим важно хорошо понимать критичность тех или иных дефектов при планировании тестирования, при описании дефектов и подготовке рекомендаций.
2. Недостатки в планировании процесса тестирования. Во многих случаях при планировании тестирования чрезмерное внимание уделяется тестированию функциональности в ущерб тестированию потенциального взаимодействия и системных характеристик. Недостаточное внимание к документации по тестированию и к документации по инсталляции также довольно рискованно.
3. Неправильный подбор персонала для тестирования. Функцию тестирования нельзя поручать младшему персоналу. Группа тестирования должна включать специалистов ИТ по системе и конечных пользователей. Группа тестирования не может действовать эффективно, если ее состав не диверсифицирован.
4. Слабая методика тестирования. Точно так же, как программисты часто предпочитают кодирование написанию алгоритмов, тестирующий персонал часто уделяет чрезмерное внимание самим тестам в ущерб времени, отведенному на составление планов тестирования. Тесты должны дать подтверждение, что программный продукт способен адекватно выполнять свои функции.
Внедрение систем - это комплекс специфицеских задач, выполнение которых позволяет добиться реальной эксплуатации решения в организации. Другими словами, это внедрение изменений, которое мы уже разбирали выше.
В общем случае процесс внедрения состоит из ряда организационных действий, подготовительных работ технического и административного плана, тестовой (опытной) и промышленной эксплуатации. Далее мы рассмотрим эти составляющие.
Внедрение, пожалуй, - самый ответственный момент проекта замены информационной системы. Это связано с рядом причин.
Во-первых, как мы уже отмечали при рассмотрении управления изменениями, это всегда наиболее сложная составляющая работы.
Во-вторых, даже если на предыдущих стадиях была создана очень хорошая информационная система, до тех пор, пока она не внедрена, ее ценность равна нулю. Часто менеджеры стараются до бесконечности совершенствовать продукт, наслаждаясь им в узком кругу программистов и ИТ-экспертов, не понимая, почему ни у кого больше их многолетние изыскания не вызывают оптимизма.
В-третьих, внедрение - это не экзамен, а нечто большее, и поэтому даже блестяще оттестированные и подготовленные системы, сдавшие все "экзамены", могут не подойти по тем или иным причинам. Думать, что заранее можно предвидеть все проблемы, недальновидно. Во время внедрения все проблемы, конфликты, которые не были решены ранее, были забыты или решены неправильно, отложены, недодуманы, скрыты, всплывают практически в один момент, требуя непомерных профессиональных знаний и личных усилий всех участников проекта.
На практике часто бывает так. Внедрение хорошо подготовлено: проведены многочисленные выверки данных, тестирование и многие другие, важные для внедрения, работы (о чем мы еще будем говорить далее). Но почему-то внедрение срывается, ком проблем растет с такой скоростью, что в один прекрасный момент большинству становиться ясно, что система не может быть внедрена. Проектная команда, менеджмент теряют веру, количество проблем от этого возрастает еще больше, и в конечном счете проект останавливается или приостанавливается высшим руководством.
Можно ли избежать этого? Ответ практикующих менеджеров проектов в 99,9% случаев - "да". Набор инструментов для достижения такого результата достаточно уникален и индивидуален и является во многом профессиональным ноу-хау (Know-How) руководителя проекта. Мы же рассмотрим некоторые основные составляющие таких организационных действий, которые позволяют сделать даже проблемное внедрение успешным.
Снятие противоречий и конфликтов. Первый вопрос, который необходимо прояснить, - всем ли нужно внедрение как в самой организации, так и среди подрядчиков? Кому оно невыгодно по тем или иным причинам? Кто против в настоящее время или был против на ранних стадиях проекта? Кто не принимал участия? Даже это может быть важно, потому что успех одного руководителя может автоматически снижать авторитет тех, кто не верил в исход проекта или был против него. Не стоит искать конфликты только среди руководства, они могут быть и на более низком уровне и при этом иметь очень большое значение. Задача руководителя проекта состоит в том, чтобы не только найти все эти центры противоречий и конфликтов, но и свести их на нет или по крайней мере добиться, чтобы их влияние на проект было минимальным.
Прояснение недопониманий и выработка согласованных подходов. Даже там, где нет предпосылок для конфликта, он может возникнуть по причине недопонимания. Внедрение является сложной задачей, и поэтому неминуемо в процессе работ, а особенно на их завершающей стадии, возникают такие ситуации, когда, не решаясь задать лишний вопрос, те или иные участники процесса просто не понимают смысл определенных действий или понимают его неправильно. Задача руководителя проекта - не только добиться того, чтобы количество таких недопониманий было минимальным, его задача также состоит в том, чтобы инициировать процедуры согласования позиций, их обсуждения и понятного и доступного формального закрепления в бумажной форме. Он должен как можно больше задавать вопросов всем участникам, чтобы добиться в конце концов одинаковых и согласованных позиций и полного понимания участниками и заинтересованными сторонами того, что происходит.
Прояснение формальной (юридической) позиции - тоже важная составляющая организационных действий. Выполненная до начала внедрения, посредством дополнительного анализа существующих формальных или договорных отношений между сторонами, она способна оказать реальную помощь в реализации двух предыдущих пунктов. Инициатором этой работы должен выступать руководитель проекта. При выявлении неясностей в формальных отношениях сторон их проясняют обязательно до начала внедрения, чтобы не приостанавливать его или не служить еще одним дополнительным риском.
Онлайн-менеджмент и контроль. Во время внедрения осуществляются постоянный надзор и контроль со стороны высшего менеджмента за происходящим. Он должен быть организован в онлайн-режиме, то есть участники проекта, его руководство имеют приоритетное право на взаимодействие с высшим менеджментом организации. Контроль должен осуществляться на оперативной и регулярной основе. Заседания управляющего комитета должны проводиться чаще, чем при обычной работе, и не реже одного раза в неделю. Не исключен и ежедневный вариант. Формальная отчетность и информация по ходу проекта должна быть доступна всем заинтересованным сторонам также на оперативной основе.
Оперативный анализ рисков. Отдельно руководителем проекта с помощью ведущих экспертов по основным областям ведется анализ рисков внедрения. Его форма должна быть простой и понятной. Это может быть просто текстовый список проблем, где указывается следующая информация: кто инициировал занесение проблемы в список, ее номер (если есть), суть проблемы, ответственный за решение, дата регистрации проблемы, дата решения, кратко основные действия по решению, приоритет и текущий статус (решена или нет). Такой список очень помогает руководителю проекта не забывать обо всех возникающих проблемах и в тоже время является инструментом контроля и давления на исполнителей, ответственных за решение.
Мотивация персонала на достижение результата. Возможно, самый главный пункт - это мотивация всех участников проекта и прежде всего его непосредственных работников на достижение результата. Мы уже останавливались на основных подходах по мотивации, когда рассматривали управление ИТ-персоналом, поэтому не будем здесь повторяться.
Широкое информирование заинтересованных сторон. Отдельная задача в ходе внедрения - информирование всех заинтересованных сторон, включая обычных сотрудников организации, о ходе и статусе работ. При недостатке информирования проект обрастает слухами, которые будут очень мешать в работе. С другой стороны, поддержка со стороны всей организации очень полезна для работы, является дополнительным источником мотивации. Но это возможно только при наличии информации и понимания, в противном случае отношение будет очень негативным.
Качественное и детальное планирование и обеспечение ресурсами. Планирование важно всегда, но на этапе внедрения оно имеет повышенное значение. Помимо этого целесообразно иметь небольшой резерв ресурсов, которые могут быть временно сняты с других работ или привлечены на отдельные участки со стороны. Все стандартные методики управления ресурсами, такие, как сетевое планирование, использование методики критического пути, должны использоваться руководителем проекта для получения информации и оперативного принятия решений по переброске ресурсов или их увеличению.
Существенная часть временных затрат при внедрении систем должна быть потрачена на подготовительные работы технического и административного характера. Данные работы включают:
* доработку программного обеспечения и его тестирование;
* подготовку компьютерной техники, приведение ее к необходимым техническим требованиям разработчика;
* обучение пользователей и администраторов системы;
* разработку конверторов данных из существующей системы в новую, разработку и тестирование методик контроля правильности переноса данных;
* разработку руководств пользователей и администраторов системы;
* разработку инструкций на случай технологических сбоев в системе.
Окончанием подготовительного периода должна стать тестовая эксплуатация системы с участием конечных пользователей. В случае небольших организаций и незначительного документооборота возможна параллельная работа обоих систем. Однако в крупных организациях параллельное ведение - весьма затратное и беспокойное мероприятие. В этом случае лучше применить поэтапное тестирование различных составляющих с участием сотрудников соответствующих подразделений.
По результатам опытной эксплуатации рекомендуется составить акт, в котором регистрируются все недоработки системы, а также сроки их устранения. При этом в случае наличия критичных недостатков, способных привести к технологическому сбою в работе организации, после их устранения необходимо провести повторное тестирование всех составляющих системы. Таким образом, после полнофункционального тестирования до начала рабочей эксплуатации системы вводится мораторий на внесение изменений в систему. Это делается для того, чтобы в результате внесения исправлений не были порождены новые ошибки.
Начало рабочей эксплуатации является самым критическим моментом в проекте. Фактически успешный старт и работа в системе хотя бы в течение нескольких дней означают успех проекта. Конечно, наличие большого количества недоработок, кажущиеся неудобства в работе, периодические сбои не позволяют сказать об этом сразу, но все эти проблемы намного более просты в решении, чем поддержание двух информационных систем и постоянная синхронизация данных в них.
Но начало рабочей эксплуатации и, как следствие, отказ от поддержки старой системы не могут основываться только на желании это сделать. Малейший сбой приводит к откату к предыдущему состоянию, к возврату эксплуатации старой системы, поскольку ни один руководитель не возьмет на себя ответственность продолжать эксперимент, когда, например, у него не проходят обработку клиентские платежи или неправильно рассчитываются процентные ставки по депозитам более чем в течение 10 минут.
В зависимости от размера организации возможны два варианта перехода на рабочую эксплуатацию. Для организации с количеством сотрудников до 100 человек, как правило, применяется тотальный переход. Все пользователи в определенный день (обычно пятницу, чтобы было время для устранения ошибок) начинают работу в новой системе. Основными показателями успешного перехода на новую систему являются отсутствие задержек приема документов у клиента, своевременная отправка платежей, получение правильного баланса.
В случае, если внедряемая система решает большой спектр задач, количество пользователей более 100, необходим поэтапный переход. Он может осуществляться в следующей последовательности:
- запуск интерфейса взаимодействия с внешними платежными системами, маршрутизация платежей филиалов;
- формирование баланса и прочей ежедневной и оперативной отчетности;
- ввод простейших платежных документов в систему пользователями, ведение расчетно-кассового обслуживания;
- учет сложных операций (покупка-продажа валют);
- автоматическое начисление процентов и платы за обслуживание;
- формирование документопотока в соответствии с перспективной моделью организации, изменение обязанностей сотрудников, участвующих в расчетно-кассовом обслуживании клиентов и собственных платежей банка;
- учет операций физических лиц;
- учет внутренних операций банка: расчет зарплат, ведение хозяйственных договоров, учет основных средств;
- учет и ведение кредитов банка;
- учет прочих операций банка, включая торговые операции на бирже. Такая последовательность позволяет минимизировать последствия озможных сбоев и дает время команде внедрения сосредоточиться на одной задаче, а не распылять свои силы на решение всех проблем.
Переход на рабочую эксплуатацию системы обычно заканчивается подписанием акта о проделанной работе. Однако большое количество недоработок и недовольство пользователей нельзя назвать успешным завершением. Таким образом, взаимодействие с разработчиками не заканчивается рабочей эксплуатацией, а переходит в новую стадию - сопровождение. Не стоит требовать от разработчиков немедленного устранения всех недочетов. Лучше в течение некоторого времени дать пользователям поработать с новой системой, почувствовать ее возможности и преимущества перед старой. И только после того, как отрицательные эмоции улягутся и пользователи смогут более квалифицированно говорить о достоинствах и недостатках нового решения, необходимо провести их опрос и составить план устранения действительно важных недоработок. При этом часть проблем к этому времени смогут снять сотрудники автоматизации банка. А остальные решит компания разработчика, которая, получив аргументированные и понятные претензии, не сможет отказать своему клиенту.
Таким образом, система начнет работать в свою полную силу, все больше и больше приближаясь к тому идеалу, о котором думали менеджеры и специалисты банка перед началом проекта, когда рассматривали, каким образом изменить технологию работы банка и какие нововведения ему нужны.
Анализ рисков при реализации проектов
Развитие информационных систем в современном мире требует все больших и больших инвестиций. Затраты современного коммерческого банка на решение информационных задач соизмеримы, а нередко и превосходят все остальные затраты на содержание организации. Поэтому неудачи информационных проектов очень болезненны. Но еще больший ущерб приносят упущенная прибыль, нереализованные услуги, аналитические ошибки.
Несмотря на то что все проекты начинаются с полной уверенности в их реализации и практически все они имеют хорошо разработанные бизнес-планы и достаточные бюджеты, их завершение нередко откладывается на неопределенный срок, а затраты оказываются многократно превышенными.
Мы уже упоминали, что доля неудачных проектов крайне высока. Почему это происходит и кто виноват в подобных ошибках? Наказать и уволить разработчиков и отдельных исполнителей - самое простое решение, однако это не выход, так как потом выясняется, что ошибки продолжают появляться и проект заходит в тупик.
Одной из причин этого явления нередко является отсутствие системы управления рисками. Разрабатываемые планы строятся исходя из идеального течения проекта и постоянства внешних и внутренних условий. При этом исключительные ситуации (например, неожиданные изменения в законодательстве) обычно просто не рассматриваются, не говоря уже о проработке выхода из них.
Данная глава рассматривает методику, позволяющую оценить риски при реализации крупного проекта и минимизировать потери от них. Эта методика была предложена и принята рядом западных компаний и адаптирована к отечественным условиям в результате многочисленных проектов в российских кредитных организациях. Мы уже рассматривали тему управления рисками. Остановимся на этом вопросе еще раз и более детально разберем его с точки зрения проектного управления.
В основе методики управления рисками лежат систематизация, расчет вероятности и ущерба, документирование возможных решений и профилактик, оценка допустимых затрат на профилактику и резерва проекта. Оценка проводится в денежном и временном эквивалентах, так как иногда даже при неограниченном финансовом обеспечении невозможно сделать работы быстрее определенного времени.
Типы рисков в информационном проекте
Первый этап рассматриваемых работ - определение ответственных за различные типы рисков. В зависимости от ответственности за риски их условно можно разделить на три группы.
1. Проектные риски связаны с ошибками в бюджете, графике работ, с проблемами персонала, изменением требований (вызванных как изменением текущих условий проекта, так и желанием заказчика).
К данным рискам можно отнести болезни и увольнение сотрудников, изменения в текущем законодательстве, замену представителя заказчика, контролирующего процесс, изменение мнения заказчика о проекте по ходу его развития.
Ответственным за данный тип рисков исключительных ситуаций является менеджер проекта, способность которого улаживать подобного рода конфликты и определяет его профессиональную подготовку.
2. Технические риски связаны с проблемами реализации технических решений. Основными проблемами здесь обычно являются проблемы разработки (способность разработчиков реализовать ту или иную задачу), неудовлетворительная производительность системы, внедрение и затруднения, связанные с окончательной адаптацией системы под конечных пользователей.
Ответственное лицо за решение подобных проблем - обычно технический руководитель проекта или ведущий аналитик.
3. Бизнес-риски связаны с финансовой поддержкой проекта. Неожиданные сокращения бюджета, вызванные внешними факторами, могут привести не только к сокращению проекта и задач, которые он решает, но и к его полному провалу в случае недостижения главной цели. Для компании-разработчика к данному типу рисков обычно относятся ошибки в оценке рынка данного решения. В российских организациях также к подобного рода нештатным ситуациям относится потеря интереса к проекту со стороны конечных пользователей.
Ответственным лицом в кредитной организации за подобные проблемы может быть заказчик (куратор) проекта или руководитель проектного комитета. Он должен заранее определить приоритеты и организовать резервы для решения приоритетных задач каждого этапа.
Следующим этапом проведения работ по предупреждению рисков в информационном проекте являются разработка их спецификации и системы идентификации, а также вероятностная оценка возникновения внештатных ситуаций, оценка ущерба и расчет резервов для их преодоления. Для компании-разработчика данные расчеты достаточно точны, поскольку большое количество клиентов позволяет сделать выборку для расчета статистических данных с небольшой погрешностью. К сожалению, вероятностные оценки в данных расчетах для коммерческого банка обычно являются весьма условными по причине отсутствия статистики. Для их сбора обычно предлагается набирать статистику по мере развития проекта, рассчитывая ее внутри циклов реализации проектов, а также делать более подробный анализ работ, раннее проводимых в организации. Динамический анализ рисков приведет к постоянной корректировке общих показателей, что затруднит первичное резервирование средств и проведение профилактических работ, однако механизм предупреждения внештатных ситуаций на меньшие сроки остается.
В качестве спецификации возможна разработка менеджером проекта таблицы рисков (табл. 16).
Оформление таблицы рисков проекта
┌───────────────────────┬──────┬─────────┬─────────┬──────────┬─────────┐
│ Наименование риска │ Тип │ Вероят- │Приоритет│ Сумма │Временные│
│ │ │ность, в │ │ущерба, в │потери, в│
│ │ │ % │ │ руб. │ днях │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Увеличение количества│ PS │ 60 │ 3 │ 2 000│ 2 │
│пользователей │ │ │ │ │ │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Изменение выходных│ RE │ 60 │ 2 │ 14 000│ 4 │
│отчетных форм │ │ │ │ │ │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Неподготовленный │ PR │ 30 │ 4 │ 2 000│ без │
│конечный пользователь │ │ │ │ │ затрат │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Противодействие │ PR │ 10 │ 2 │ 15 000│ 10 │
│конечных пользователей│ │ │ │ │ │
│внедрению системы │ │ │ │ │ │
└───────────────────────┴──────┴─────────┴─────────┴──────────┴─────────┘
┌───────────────────────────────┐ ┌─────────────────────────────────────┐
│ Расшифровка типов │ │ Приоритеты │
├────┬──────────────────────────┤ ├───┬──────────┬──────────────────────┤
│ PS │изменения размера системы │ │ 1 │Катастрофа│> 100 000 руб. > 20│
├────┼──────────────────────────┤ │ │ │дней │
│ RE │изменения постановки задач│ ├───┼──────────┼──────────────────────┤
├────┼──────────────────────────┤ │ 2 │Критично │> 10 000 руб. > 3 дней│
│ PR │проблемы с персоналом │ ├───┼──────────┼──────────────────────┤
└────┴──────────────────────────┘ │ 3 │Проблема │> 1000 руб. > 1 дня │
├───┼──────────┼──────────────────────┤
│ 4 │Возможно │< 1000 руб. < 1 дня │
│ │игнориро- │ │
│ │вание │ │
└───┴──────────┴──────────────────────┘
По результатам построенной таблицы рассчитываются средние показатели по всем категориям и типам, а также общий ожидаемый ущерб нештатных ситуаций в проекте (табл. 17). Расчеты производятся по следующим формулам:
"Формула 1"
"Формула 2"
Расчет уровня рисков и их влияния
┌───────────────────────────────────────────────────────────────────────┐
│ Итоговая таблица по приоритетам │
├─────────┬─────────────────────┬────────────────────┬──────────────────┤
│Приоритет│ Вероятность, │ Средний денежный │Потери времени, в │
│ │ % │ ущерб, руб. │ днях │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 1 │ 0 │ 0│ 0 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 2 │ 64 │ 9900│ 3,4 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 3 │ 60 │ 1200│ 1 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 4 │ 30 │ 600│ 0 │
├─────────┴─────────────────────┴────────────────────┴──────────────────┤
│ Итоговая таблица по категориям │
├─────────┬─────────────────────┬────────────────────┬──────────────────┤
│ PR │ 37 │ 2100│ 1 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ RE │ 60 │ 8400│ 2,4 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ PS │ 60 │ 1200│ 1,2 │
├─────────┴─────────────────────┴────────────────────┴──────────────────┤
│ Общий итог │
├─────────┬─────────────────────┬────────────────────┬──────────────────┤
│ │ │ 11 700│ 4,6 │
└─────────┴─────────────────────┴────────────────────┴──────────────────┘
Результатом данной таблицы является предварительная оценка возможного ущерба от нештатных ситуаций. Данные показатели можно внести в проект в виде страховых резервов времени и денег.
Однако основной задачей данных работ является не столько расчет резерва, сколько снижение затрат и оценка и сравнение затрат на профилактические работы с затратами от ожидаемого ущерба.
Снижение потерь возможно за счет трех действий: профилактики (предотвращения), мониторинга (своевременного распознавания ситуации) и управления критической ситуацией (правильными действиями в случае ее возникновения). Рассмотрим более подробно каждое из них.
Профилактика - некие затраты для устранения, снижения вероятности или снижения ущерба нештатной ситуации. Нередко очень трудно убедить заказчика в дополнительных затратах, особенно если угроза не очень понятна заказчику. Например, достаточно легко получить дополнительное финансирование на дополнительную проработку системы безопасности (угроза несанкционированного доступа), однако нередко очень трудно добиться обучения конечных пользователей, хотя неграмотная эксплуатация также может привести к образованию дыр в системе безопасности. И обычно только хорошо обоснованный документ с оценкой вероятности и значения ущерба может убедить заказчика в правильном распределении средств.
Мониторинг означает разработку системы показателей, определяющих возникновение той или иной проблемы, и механизмов их отслеживания. Своевременное распознавание проблемы нередко позволяет минимизировать потери или свести их к нулю. Например, отслеживание текущего законодательства и своевременное распознавание принципиальных изменений позволят существенно сократить затраты на адаптацию за счет изменений ряда концептуальных решений, таких, как изменение структуры данных или разработка новых алгоритмов. В случае, если время упущено, начинают работать механизмы латания дыр, которые приводят к усложнению системы и, как следствие, росту временных затрат на решения новых задач.
Управление критической ситуацией означает документирование и регламентирование действий в случае возникновения непредвиденной ситуации. Четкое понимание действий менеджером позволяет многократно снизить отрицательный эффект. Предварительное документирование действий позволит скорректировать расчетный эффект ущерба и, как следствие, снизить суммы резервов и сделать проект более привлекательным для инвесторов и заказчиков. Также частью работ по этому направлению может быть создание механизмов смягчения критической ситуации. Например, наличие информации о квалифицированных соискателях на работу в организации будет очень кстати при неожиданном увольнении ключевого работника.
Основой работ по сокращению затрат является разработка плана противодействия рискам проекта. Примером оформления данного плана может служить дальнейшее развитие таблицы рисков (табл. 18).
Оформление плана противодействия рискам
┌─────┬────────┬────────────────┬───────────────┬──────────────┬────────────────┬──────────────────┐
│ N │Вероят- │ Ущерб │ Подробное │ Профилактика │ Механизм │ Что делать │
│ │ ность │ │ описание │ │ мониторинга │ │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 1 │ 40% │2-кратное увел.│Потеря интереса│Максимальная │Постоянное │Попросить │
│ │ │сроков. │у пользователей│популяризация │обсуждение с│руководство │
│ │ │Профилактика = 1│к развитию│проекта, │группой │заказчика отметить│
│ │ │чел/д; │системы из-за│построение │внедрения │подразделения, │
│ │ │эффект Р = 20%; │угрозы │связи между│отношения │обеспечивающие │
│ │ │преодоление =│сокращения │эффектом от│пользователей к│наибольшую │
│ │ │6000 руб./отдел;│ │проекта и│проекту │поддержку проекта.│
│ │ │эффект = Р/2 │ │ростом доходов│ │Рассмотреть │
│ │ │ │ │ │ │исключение │
│ │ │ │ │ │ │сопротивляющихся │
│ │ │ │ │ │ │подразделении из│
│ │ │ │ │ │ │участия в проекте │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 2 │ │ │ │ │ │ │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 3 │ │ │ │ │ │ │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 4 │ │ │ │ │ │ │
└─────┴────────┴────────────────┴───────────────┴──────────────┴────────────────┴──────────────────┘
Из таблицы хорошо виден эффект от контроля за рисками, и этот факт непременно поможет менеджерам максимально контролировать весь проект в целом и более аргументированно отчитываться перед инвестором и заказчиком. Однако необходимо помнить, что управление рисками носит относительный характер и все приведенные цифры в таблице условны и служат для общей оценки нестандартных ситуаций. Также необходимо помнить о динамическом изменении основных показателей проекта, что приводит к постоянному пересчету приводимых ранее величин.
Ожидаемая в следующем году новая волна изменений в правилах бухгалтерского учета приведет российские кредитные организации к необходимости серьезной доработки или смены информационных систем. Безусловно, опыт, полученный банками в области автоматизации за прошедшее десятилетие, позволит существенно сократить потери от изменения правил и механизмов учета. Рассмотрим различные приемы, направленные на сокращение затрат при выполнении различных проектов, связанных с изменениями в текущей деятельности работающей организации.
Одним из самых эффективных путей сокращения проектных издержек является сокращение требуемых ресурсов и использование вместо них уже имеющихся.
К дополнительным ресурсам проекта, то есть тем, на которые необходимы дополнительные затраты, в кредитной организации можно отнести:
* персонал;
* помещение;
* вычислительную технику и программное обеспечение;
* коммуникации.
Как искать человеческие ресурсы для проекта, мы уже говорили. Резервом помещений в банке являются, как правило, переговорные комнаты и комнаты для конференций и заседаний. Но если проект требует долгосрочного использования помещения, то аренды или покупки дополнительного помещения скорее всего не избежать.
Резервом вычислительной техники может являться устаревшее оборудование. Часто в отделах автоматизации скапливаются устаревшие компьютеры и техника. Приведем примеры решения подобных задач.
Временному сотруднику на время проекта требуется компьютер. Можно предложить ему старый компьютер. В 70% случаев этого будет достаточно. Другой вариант: взять компьютер сотрудника, находящегося в отпуске, и заменить жесткий диск. Если сотрудник возвращается из отпуска до завершения проекта, можно переставить данные участника проекта на другой компьютер. Более простой вариант распределенного использования вычислительной техники будет доступен, если в организации для работы используются сетевые диски.
Набор задач, реализуемых на одном мощном сервере, можно разбить и использовать маломощные компьютеры. Например, почтовые и интернет-серверы для небольших рабочих групп могут быть реализованы на устаревших рабочих станциях.
Следует рассмотреть возможность обновления (upgrade) вычислительной техники. Иногда для эффективной работы приложения достаточно просто увеличить объем оперативной памяти, стоимость которой невысока.
В отношении программного обеспечения следует придерживаться позиции противостояния увеличению количества используемых программ. Все задачи надо стараться реализовывать в уже имеющихся приложениях. Особенно это относится к системам управления базами данных. Если банк работает на MS SQL Server, проект должен реализовываться на этой платформе, а не на ORACLE, и наоборот. В противном случае дополнительные затраты возрастут на суммы от $5 до 100 тысяч в зависимости от размеров организации.
Для коммуникаций также существуют некоторые резервы. Как правило, это несанкционированный трафик: от сетевых компьютерных игр до блужданий в компьютерных сетях или личных разговоров по телефону. Следует осуществлять контроль передаваемой информации по компьютерным сетям. Даже если возможности такого контроля нет, можно создать его видимость. Эффект может оказаться неожиданным и крайне позитивным для проекта.
Рассмотренный нами список резервов не является полным. Каждая организация имеет свои секреты и приемы работы, которые могли бы его дополнить. Некоторые из них, возможно, не дадут эффекта. Однако время "шальных" денег прошло, и надо использовать любую возможность их экономии, не забывая при этом, что цель - реализация проекта, а не экономия средств.
Развитие теории управления как науки в России идет по пути адаптации западных технологий управления к нашей действительности. Однако нередко анализ показывает, как правило, если не негативное влияние западных школ, то отсутствие положительного эффекта. Данная глава предлагает к рассмотрению одну из российских технологий поиска решений - "Теории решения изобретательских задач" (ТРИЗ), разработанную Генрихом Альтшуллером и группой единомышленников, которая была очень популярна до перестройки и успешно применялась для решения технических задач. Универсальность основного алгоритма поиска решений позволяет использовать ТРИЗ и в гуманитарных науках. Основной особенностью данного подхода является принципиальная возможность решения нестандартных задач, чего не позволяют сделать западные методики. Рассмотрим возможность применения ТРИЗ в проектном управлении.
В основе теории лежит алгоритм решения задач (АРИЗ), который представляет собой последовательность необходимых действий в процессе поиска решения. При выполнении каждого этапа необходимо тщательно обдумывать его результаты и обязательно записывать все соображения, возникающие по ходу выполнения задачи. Алгоритм содержит девять этапов. Однако нужный ответ может появиться на любом из них. При этом рекомендуется продолжить выполнение алгоритма, так как возможно получение нового решения, превосходящего по результатам уже имеющееся.
Рассмотрим составляющие АРИЗ и попытаемся найти решения для некоторых задач, которые приходится решать менеджерам проектов в коммерческом банке. Описанный ниже алгоритм содержит некоторые отличии от алгоритма, разработанного Альтшуллером, так как был адаптирован авторами под задачи проектного управления.
Итак, первый этап - это анализ. Основная цель первого этапа - переход от расплывчатой ситуации к четко построенной и предельно простой схеме задачи. Этап содержит семь действий, позволяющих четко сформулировать задачу и выявить основные противоречия.
1. Записать условия мини-задачи (без специальных терминов) по следующей форме.
Участники процесса. Указать цели и задачи каждого участника, его возможности и связи. Указать особенности каждого участника и (в случае, если участник - организация или любая другая группа людей) его составляющие.
Противоречия. Перечисляются все противоречия.
Что необходимо при минимальных изменениях. Указать результат, который должен быть получен. Мини-задачу получают из общей проблемы, вводя ограничения: все остается без изменения или упрощается, но при этом задача достигает своего решения или исчезает противоречие. Переход к мини-задаче не означает, что начато решение основной задачи. Наоборот, введение дополнительных ограничений (результат должен быть получен из ничего) ориентирован на обострение конфликта и заранее отрезает пути к компромиссным решениям.
Пример мини-задачи.
Участники процесса:
сотрудник "А". Хороший специалист, знает учет, пользуется уважением в коллективе;
сотрудник "В". Имеет связи за пределами организации. Однако груб с коллегами, имеет ряд недостатков.
Противоречие: между ними имеется скрытое соперничество, выдвижение одного может привести к увольнению другого. В случае увольнения сотрудник "А" может увести с собой и других сотрудников отдела, что существенно нарушит деятельность организации. В случае увольнения сотрудника "В" будет потерян важный клиент.
Необходимо при минимальных изменениях: назначить нового руководителя отдела, удержав обоих сотрудников в организации.
Термины и понятия в описании задачи следует заменять простыми словами без дипломатических уверток. Например, фразу "имеет связи" лучше поменять на описание этих связей: "супруг является директором данной фирмы"; "привел этого клиента в банк (имя); знакомство (учились в одном классе с начальником отдела маркетинга)". Согласитесь, что описание влияния сотрудника "В" в фирме клиента существенно расширяется.
В нашем случае конфликтующей парой являются сотрудники "А" и "В". Данный этап требует дополнительно проанализировать данных сотрудников, учитывая следующие параметры:
* развитие ситуации во времени. В рассматриваемом случае необходимо оценить дальнейший карьерный рост каждого из них, а также их ожидания в продвижении по карьерной лестнице. Например, если очевидно, что один из сотрудников долго на предлагаемой должности не задержится, это может существенно повлиять на принятие вашего решения;
* силу связи участников конфликта с окружающей средой. Здесь надо еще раз оценить, насколько сильно участник конфликта может оказывать влияние на окружающих;
устойчивость участников конфликта к психологическому воздействию. Данный пункт отсутствует в АРИЗ, поскольку технологические процессы не поддаются психологическому воздействию, однако в гуманитарной области это воздействие часто оказывается решающим.
3. Построение графической схемы конфликта.
Очень многие технологии, связанные с поиском решений, рекомендуют графическое отображение процессов. Это объясняется повышенной восприимчивостью человеческого мозга к графическим образам. АРИЗ также предполагает построение подобных графических схем. Какого-то единого стандарта, как, например, в IDEFO, здесь нет. Единственное условие - простота и понятность.
Шаги 2 и 3 уточняют общую формулировку задачи. Поэтому после третьего шага необходимо вернуться к первому, проверить несоответствия и скорректировать их.
4. Выбор типового решения, которое обеспечивает наилучшее осуществление главного процесса.
Этот шаг не приводит к полному решению задачи, однако заставляет провести оценку конфликта и его последствий. Насколько на самом деле увольнение одного из рассматриваемых сотрудников критично для организации? На какие затраты может пойти организация для разрешения данного конфликта? В дальнейшем оценка ущерба от конфликта станет одним из основных параметров поиска решений
5. Построение модели самого плохого развития ситуации. Данный шаг является развитием предыдущего во времени, поскольку значение разовых потерь может быть существенно меньше, чем ущерб, который получит организация впоследствии. Например, в нашем случае это могут быть неуверенность и чувство несправедливости у оставшихся сотрудников, что может привести их к поиску нового места работы.
6. Окончательная формулировка задачи.
Все вышеперечисленные шаги позволяют провести окончательную формулировку задачи, которая должна содержать в себе помимо описания мини-задачи следующие составляющие:
- участников конфликта;
- оценку ущерба, равную наихудшему развитию ситуации при выборе лучшего стандартного решения;
- требования к Х-элементу (под Х-элементом подразумевается изменение в системе, направленное на достижение поставленной цели).
В нашем случае задача будет примерно такой: сохранить профессиональный коллектив отдела, повысив реального лидера коллектива, и при этом не потерять клиента, представитель которого претендует на должность руководителя.
1. Проверить возможность применения стандартных решений подобных задач из разных областей жизни.
В стандартном описании "алгоритма решения задач" систематизация стандартных решений является достаточно большой областью теории, выходящей за рамки данной главы. Для простоты мы воспользуемся простым перебором возможных решений проблемы, когда два объекта стремятся занять одну область. Вот возможные решения.
Разнесение во времени. Сначала вакансия отдается одному сотруднику, затем он переводится на другую должность, и место отдается второму сотруднику.
Разделение области на подобласти. Под данным решением подразумевается разделение основных атрибутов вакансии руководителя на два списка и распределение их между участниками конфликта. Например, сотрудник "А" получает реальную власть в принятии решений, распределении работ, ответственность за результат. Сотрудник "В" получает звание и администраторские функции. Реально этого можно достичь, выделив сотрудника "А" в отдельный проект, контролируемый высшим руководством организации.
Дублирование области. Это часто применяемое решение, заключающееся в создании должности специально под сотрудника с целью удовлетворения его амбиций.
Не решать задачу. Поскольку негативные последствия в рассматриваемом конфликте начинаются только после принятия решения, то одним из решений может стать его отсутствие, что, возможно, приведет к отсутствию конфликта. Учитывая динамичность области задачи, можно ожидать изменения рассматриваемой системы и исчезновения конфликта решений.
Удаление лишнего звена системы, приводящего к конфликту. Если еще раз внимательно перечитать условия задачи, то становится видно, что организации не интересен сам сотрудник "В". Условия требуют сохранения клиента. Сотрудник является всего лишь связующим звеном. Возможно, следует пересмотреть условия задачи и рассмотреть новую задачу по созданию новой связи между организацией и клиентом без посреднических услуг сотрудника.
Помимо этих чисто технических решений для задач управления возможны и психологические решения. Среди них:
подмена цели. Данное решение включает в себя попытку убедить одного из сотрудников, что его настоящая цель заключается не в занимаемой должности, а, например, в финансовом благополучии. В результате, правда, придется повысить одному из них заработную плату;
отвлечение внимания. Увлечь сотрудника решением новой задачи или новым проектом, что сделает потерю должности не столь болезненной и не приведет к критической точке конфликта.
Нет сомнений, что существуют и другие решения рассматриваемой проблемы. Но, так или иначе, задача подобной сложности скорее всего будет решена именно на первом этапе, основной идеей которого является необходимость как следует разобраться в проблеме. Возможно, решение появится само собой. При рассмотрении следующих этапов мы усложним пример и рассмотрим, к каким неожиданным и красивым решениям может привести использование данного алгоритма.
Второй этап - анализ ресурсов. "Цель второго этапа - учет имеющихся ресурсов, которые можно использовать при решении задачи".
Второй этап состоит из трех шагов: определения оперативной зоны, определения оперативного времени и определения финансово-производственных ресурсов. В качестве примера для анализа будет рассматриваться проблема ликвидности активов: "Организации срочно требуются свободные средства для осуществления текущих платежей по договору, однако имеющиеся у нее активы являются низколиквидными. Необходимо найти решение преобразования данных активов в свободные средства с минимальными потерями в определенные сроки".
1. Определение оперативной зоны. В простейшем случае оперативная зона - это область, в пределах которой возникает конфликт, указанный в модели задачи, ограниченная правовыми и этическими рамками. Границами этой зоны является свод обязательных правил, нарушение которых недопустимо при решении задач и. Наиболее часто используются следующие ограничения:
- соответствие законодательной базе - при описании данных ограничений следует четко определить области действия законов. Необходимо контролировать пересечение областей действия задачи и действия различных законов;
- соответствие нормам поведения в обществе и внутренним регламентам.
2. Определение оперативного времени. Оперативное время - это имеющиеся ресурсы времени: время до конфликта и время продолжительности конфликта.
В рассматриваемом примере время до конфликта - это время на подготовку операции перевода активов в свободные средства, время продолжительности конфликта - это время, требуемое на саму операцию. Соответственно сумма обоих временных интервалов должна быть меньше времени до начала платежа.
3. Определение оперативных ресурсов (инструментов). Ресурсы - это средства, доступные в оперативное время в оперативной области для решения задачи. Применительно к задачам управления определяются следующие типы ресурсов:
* ресурсы времени;
* финансовые ресурсы;
* производственные ресурсы;
* людские ресурсы.
При этом следует помнить, что нехватка одного вида ресурсов при решении задачи может компенсироваться избытком другого ресурса, хотя и не всегда. Например, нехватка людских ресурсов может быть компенсирована автоматизацией процесса, то есть производственным ресурсом.
По отношению к области задачи ресурсы также делятся на 3 вида:
1) внутрисистемные - к данному типу относятся ресурсы участников конфликта и внутренние инструменты. Например, находящиеся в активах здания можно сдавать, что даст дополнительные средства. Также возможно в случае, если активы находятся в залоге у организации, попытаться ускорить процесс возврата выданного под данный ресурс кредита;
2) внешнесистемные - к данному виду относятся ресурсы внешней среды, как специфичные для данной задачи, так и общего плана. В рассматриваемом примере это могут быть различные варианты межбанковского кредитования, торговые операции;
3) надсистемные - обычно под данным видом рассматриваются "отходы" посторонней системы или недорогие ресурсы (очень дешевые посторонние элементы, стоимостью которых можно пренебречь). Часто в российской практике к подобным ресурсам относят внеурочное время работы сотрудников, которое не всегда оплачивается дополнительно.
На данном шаге рассматриваются только имеющиеся ресурсы. Их выгодно использовать в первую очередь. Если их окажется недостаточно, в дальнейшем можно расширить поиск. Анализ ресурсов на данном этапе является предварительным.
Определение идеального решения
Третий этап - определение идеального решения. В результате применения третьего этапа АРИЗ должен быть сформулирован образ идеального решения (ИР). Определяются также физические противоречия, мешающие достижению ИР. Не всегда возможно достичь идеального решения, но ИР указывает направление на наиболее сильный ответ.
Для описания идеального решения выполняются следующие шаги.
Записать первую формулировку идеального решения исходя из следующих условий: данное решение, не усложняя существующую систему и не вызывая вредных последствий в течение оперативного времени в оперативной области, должна устранять существующий конфликт, сохраняя основной процесс задачи.
Применительно к рассматриваемой выше задаче первичная формулировка идеального решения может звучать так: данное решение осуществляет своевременную оплату необходимых средств, при этом объем имеющихся активов уменьшается не больше чем на сумму платежа, без каких-либо последствий.
Следует учитывать, что данное описание носит первичный характер, так как очень трудно оценить последствия любого решения, связанные с усложнением системы или воздействием на внешнюю среду.
Усилить формулировку идеального решения дополнительным требованиям использования только оперативных ресурсов. Ограниченность набора оперативных ресурсов позволяет произвести оценку эффективности использования всех их видов и типов, при этом вырабатываются различные возможные линии решений, сформированных путем использования разных типов инструментов и свойств участников задачи. Оценить, какая из линий максимально близко подходит к идеальному решению. При прохождении АРИЗ последовательный анализ постепенно заменяется параллельным. Решение задачи сопровождается ломкой старых представлений. При работе с АРИЗ записи необходимо вести, всячески избегая спецтерминов, поскольку они усиливают психологическую инерцию.
Записать формулировку физического противоречия на макроуровне. Физическим противоречием называют противоположные требования к состоянию оперативной зоны. Например, требование выполнения работы в срок и качественно. При достаточно малом сроке работа не может быть выполнена качественно. В примере с ликвидностью активов противоречие может звучать так: невозможно осуществить беззатратное преобразование одних видов активов в другие. При этом размер затрат определяется оперативным временем задачи. Чем меньше время, тем больше потери.
Рекомендуется также графическое отображение противоречия с отображением воздействия на задачу различных видов решения (рис. 23).
"Рис. 23. Графическое отображение противоречий и возможных решений"
Записать формулировку конечного варианта идеального решения. Три первые этапа АРИЗ существенно перестраивают исходную задачу. Итогом этого процесса являются окончательная формулировка идеального решения и физическое описание задачи. Именно понимание того, что физически невозможно в рассматриваемой проблеме, и делает задачу готовой к окончательному решению по методологии ТРИЗ. Получив физическое описание проблемы, необходимо еще раз просмотреть систему стандартных решений для данной физической задачи. И если она не решена, то переходить к следующему этапу.
Четвертый этап - мобилизация новых ресурсов с целью расширить ресурсную базу, доступную для решения задачи. Данный этап заключается в переборе различных приемов, направленных на увеличение доступных ресурсов и методов их применения для решения задачи. Для поиска новых ресурсов в качестве примера будет использоваться рассматриваемая выше задача нелеквидности активов.
1. Объектное разделение задачи является первым шагом расширения ресурсной базы. При этом определяются инструменты, способные оказывать воздействие на каждый объект задачи, и методы собственно объектов. На данном этапе также рекомендуется применять графические изображения задачи.
В примере мы определим объекты, их методы и методы воздействия на них.
Здание (неликвидный актив) - продажа, залог, сдача в аренду, получение страховки, передача в качестве доли в сторонних проектах, использование для развития собственного бизнеса.
Свободные средства - заем, прибыль, отсрочка других платежей или различные варианты экономии, выпуск векселей.
Платеж - перенос срока платежа, изменение суммы платежа, изменение формы платежа (замена денежной суммы на право владения тем же зданием или на акции самого банка, или на векселя организации).
Возможно, существуют еще множество различных методов рассматриваемых выше объектов, но для примера достаточно и этих.
Из приведенных списков начинают проглядываться принципиально новые доступные решения (передача части имущественного права в качестве платежа или предложения по участию получателя платежа в новом проекте). Возможно, подавляющее число подобных решений более удалены от идеального решения, чем типовые решения, однако среди них возможно присутствие инструмента, позволяющего улучшить показатели уже лучшего из имеющихся решений.
2. Рассмотрение возможности решения задачи смешением различных ресурсов. На данном этапе рассматривается возможность одновременного использования доступных ресурсов. Строятся различные модели решения и рассматриваются влияния каждого из ресурсов на изменения параметров линии решения. В примере отсрочка других платежей и экономия средств могут снизить требуемые денежные ресурсы до такой степени, что появится возможность получения дешевого кредита под залог целого здания без дополнительных экспертиз.
3. Рассмотрение возможности решения задачи ресурсами, являющимися производными от имеющихся. Для того чтобы получить производные ресурсы и методы, необходимо изменить статус имеющихся объектов. Следует попытаться описать имеющиеся объекты другими словами и оценить доступные методы новых понятий.
4. Рассмотрение возможности решения задачи с использованием психологических методов. На данном этапе рассматривается возможность изменения требования к условиям задачи со стороны других людей путем психологического воздействия на них. Даже если получателю платежа не нужны векселя, есть смысл попытаться убедить его в возможности данного решения. Использование психологических методов может оказаться очень эффективным на первом этапе. Однако часто данные методы имеют негативные последствия, поэтому требуется дополнительный анализ их нейтрализации.
Применение информационного фонда
Во многих случаях четвертый этап АРИЗ приводит к решению задачи, однако если ответа до сих пор нет, надо пройти пятый этап, цель которого - использование опыта, сконцентрированного в информационном фонде. К данному этапу задача достаточно проясняется, чтобы эффект от использования информационного фонда был максимальным.
На этом этапе подключаются все возможные источники знаний и типовых решений. К наиболее распространенным источникам относятся:
* знания и опыт окружающих людей;
* литература;
* Интернет;
* специализированные эксперименты;
* консультанты.
При работе с информационным фондом рассматриваются примеры решения похожих задач и опыт использования имеющихся ресурсов. В случае отсутствия какой-либо информации проводятся эксперименты. Кроме того, следует помнить, что каждый человек имеет свой собственный информационный фонд, возможно, включающий в себя недоступные вам источники информации.
Шестой этап - изменение или замена задачи. Простые задачи решаются буквальным преодолением противоречий, например разделением конфликтующих объектов во времени или пространстве. Решение сложных задач обычно связано с изменением смысла задачи - снятием первоначальных ограничений и психологической инерции. Процесс решения на данном этапе в сущности есть процесс корректировки задачи.
Для изменения задачи используются следующие шаги.
Проверить, не является ли формулировка задачи сочетанием нескольких разных задач. Например, как уже стало очевидным, задачу с ликвидностью можно разделить на две: превращение актива в свободные средства и осуществление платежа при отсутствии средств.
Рассмотреть более общую задачу. Для кредитной организации задачей более высокого уровня может быть получение стабильного дохода. Рассмотрение с точки зрения человека, занятого решением этой задачи, других задач может свести их к проблеме, как выкрутиться из создавшейся ситуации с минимальными потерями. Однако не стоит очень углубляться в обобщение задачи, так как в конечном этапе в результате подобных переходов будут достигнуты общечеловеческие ценности, такие, как материальные блага, стабильность, здоровье и т.п., что может увести от решения конкретной проблемы.
На этом этапе АРИЗ заканчивает собственно поиск решения. В случае отсутствия решения шестой этап входит в бесконечный цикл по изменению условия задачи, в каждом из которых приходится повторять 1-6 этапы соответственно.
Последующие этапы связаны с оптимизацией имеющегося решения и его преобразования в универсальное для решения для последующих задач. К этим этапам следует также обращаться в случае, если решение было найдено раньше шестого этапа.
Седьмой этап - проверка полученного ответа, анализ способа устранения противоречия задачи. Главная цель седьмого этапа АРИЗ - проверка качества полученного ответа. Противоречие должно быть устранено почти идеально, с минимальными затратами. Лучше потратить время на получение более сильного решения, чем потом бороться за трудновнедряемую идею.
Анализ решения. Для проведения подобного анализа следует ответить на следующие вопросы:
* Обеспечивает ли полученное решение выполнение главного требования идеального решения?
* Какое противоречие устранено (и устранено ли) полученным решением?
* Управляема ли полученная система?
* Будет ли данное решение работать многократно?
Построение плана внедрения найденного решения. Результатом данного шага должен стать бизнес-план реализации предложенного решения с оценкой затрат на его реализацию. При этом необходимо провести сравнение положительного эффекта и затрат на реализацию и поддержку данного решения. В случае, если решение не применялось ранее и не может быть применено в будущем, рекомендуется как минимум двукратное превышение ожидаемой выгоды над затратами. Если затраты на реализацию слишком высоки, рекомендуется продолжить оптимизацию решения путем анализа эффективности использования дополнительных методов и ресурсов.
Переносимость найденного решения на другие задачи
Восьмой этап - переносимость найденного решения на другие задачи. Действительно хорошая идея не только решает конкретную задачу, но и дает универсальный ключ ко многим другим аналогичным задачам. Цель этапа - максимальное использование ресурсов найденной идеи.
Обычно менеджеру приходится решать однотипные задачи, поэтому любое решение, реализованное успешно, может применяться многократно. В общем случае этот этап не нужен для решения задачи, однако его прохождение может дать большой дополнительный эффект. Однако, если работа ведется не только ради решения конкретной задачи, выполнение этого этапа может стать началом разработки новой концепции управления. Этап включает в себя следующие шаги.
1. Определение изменения в системе более высокого уровня. Необходимо еще раз сформулировать основную идею и рассмотреть, как она повлияла на различные внешние системы.
2. Проверить, сможет ли решенная задача применяться в других ситуациях. Например, если вы в первом примере про двух сотрудников нашли метод, как устанавливать добрые отношения с клиентом, минуя их представителей в вашей организации, разве этот метод недостоин быть примененным ко всем клиентам или использован для привлечение новых? И наоборот, если вам удалось сохранить коллектив, избегнув продвижения в карьере, разве вы не будете использовать этот прием снова и снова?
3. Попытайтесь менять условия задачи, сохраняя общий принцип ее решения. Увеличивайте значения параметров задачи до бесконечности и уменьшайте до нуля, определите диапазон, в котором данный принцип работает, и область наибольшего эффекта. Данный принцип становится особенно понятен в примере с ликвидностью. Уменьшая сумму платежа, вы придете к сумме, которую вы сможете оплатить из своего кармана и, следовательно, ограничить область применения задачи снизу.
4. Рассмотрите возможность использования принципа обратного полученному. Если вы нашли метод, как удержать сотрудника, может быть, где-то рядом находится метод, как от него избавиться.
Девятый этап - анализ хода решения. Как уже говорилось, сама по себе рассматриваемая методика носит общий характер. Она позволяет лишь систематизировать поиск правильного решения. Если вы допустили отклонение от него, постарайтесь проанализировать его причины. И если изменения оказали явно положительный результат, необходимо зарегистрировать их. Однако надо учитывать, что изменения алгоритма, оказавшие положительный эффект при решении одной задачи, могут затруднить решение другой задачи.
При реализации проектов в области ИТ в первую очередь стоит помнить об их основной цели - содействии развитию бизнеса, внедрению передовых технологий и решений. Но эффективное развитие невозможно, если в организации не приветствуются инновации и нововведения. Поэтому цель - поддержка изменений. Но что такое изменения и зачем они нужны? Как управлять этим процессом? И какое все это имеет отношение к проектному управлению в области ИТ?
Одним из принципиальных моментов, определяющих эволюцию каждого менеджера и организации в целом, является осознание необходимости постоянных изменений. Как только организация хоть на время "останавливается" или просто уменьшает темп своего развития, она начинает сразу сдавать свои позиции.
Постоянные изменения стали одним из отличительных знаков нашего времени. Они затрагивают практически все области. Меняется сам уклад жизни, восприятие людей, хозяйственные отношения.
Непрерывно изменяющаяся внешняя среда уже сама по себе обусловливает для коммерческих организаций необходимость следовать всем новейшим тенденциям. Многие возразят, что "здоровый" консерватизм еще никому не мешал. Однако правы они будут лишь отчасти. Когда-то консерватизм, возможно, и был обязателен во многих сферах деятельности, но в настоящей экономической ситуации он является полным анахронизмом. Это можно хорошо проиллюстрировать на примере таких, как считалось раньше, консервативных сфер бизнеса, как банковское дело или страховой бизнес. Сегодня они отвергают большинство традиционных подходов и активно меняют практику своей работы, не боясь "кидаться в омут" неизведанного и нового. Связано это с тем, что, не отслеживая тенденции рынка, запросы потребителей, новейшие технологические достижения, сегодня невозможно удержать как собственные позиции, так и своего клиента, который становится более требовательным.
Не двигаться вперед - значит, двигаться назад. Этот тезис сегодня очевиден, но не так очевидны его предпосылки, а также причины возможного регресса. Попытаемся разобраться в них и обосновать необходимость постоянных преобразований.
Одной из основных причин такой необходимости можно назвать технологическую революцию последних десятилетий. Большинство других причин являются во многом следствиями глобальных изменений в научно-технической и технологических сферах. Именно они принципиально изменили картину гиперэкономического пространства, создав новую в истории человечества экономическую ситуацию, при которой потенциальное предложение на большинстве рынков существенно превышает спрос.
Практически всю историю человечества картина была обратной. Спрос в глобальном отношении был почти всегда ниже предложения, а на уровне отдельных рынков они уравновешивали друг друга в основном за счет ценового механизма. Кроме того, традиционная система экономических отношений в области макро- и микроэкономики базировалась на опыте предшествующих столетий. То есть при осуществлении деятельности в сфере производства или услуг, в том числе и в процессе менеджмента, не предполагалось, что предложение может в несколько раз превысить спрос или что спрос вообще будет отсутствовать.
Но картина неожиданно изменилась, и изменилась именно вследствие технологической революции, которая выразилась в резком росте производительности труда, перепроизводстве товаров и услуг, снятии коммуникативных и торговых барьеров, повышении уровня жизни в подавляющем большинстве стран, что в свою очередь кардинально изменило отношения производителей с потребителями, клиентами и, что вполне закономерно, в этой ситуации резко обострило конкурентную борьбу. Последние две причины в максимальной степени отразились на экономических отношениях в различных сферах коммерческой деятельности, в том числе в банковском секторе экономики.
Клиенты стали не просто требовательными, но и грамотными. Кроме того, если десять лет назад производители "боролись за клиентов", то сегодня все успешные организации констатируют, что им приходиться "бороться не просто за клиентов, а уже за каждого клиента". Мы об этом говорили, когда рассматривали стратегию развития ИТ. Так, например, если раньше для банков основной интерес представляли крупные корпоративные клиенты, то сегодня идет борьба даже за самое маленькое предприятие с ничтожными оборотами и несколькими работниками. А за рубежом ситуация еще в несколько раз жестче. Там давно идет борьба и за таких, казалось бы, недоходных для банка клиентов, как частные лица, пенсионеры и студенты. Естественно, связано это напрямую с перепроизводством и другими следствиями технологической революции.
Другая важная причина, толкающая коммерческие организации на путь постоянных изменений, как мы уже отмечали, - активная конкурентная борьба. Она последние несколько лет активно ведется и в России. На весьма "прозрачном" банковском рынке все действия хорошо заметны, и это еще одна новая реалия, являющаяся следствием технологической революции. Рынки стали прозрачны и открыты, как никогда ранее. В этой ситуации достаточно какому-либо банку совершить ошибку или просто понизить качество предлагаемых услуг, он сразу начинает терять клиентскую базу. В то же время необходимо помнить, что даже высокоразвитому банку необходимо совершенствоваться, так как все положительное в его работе и технологиях достаточно быстро становится известным на рынке и активно внедряется конкурентами. Поэтому, чтобы находиться хотя бы в незначительном отрыве от конкурентов, необходимо постоянное изменение.
Еще одно следствие технологической революции заключается в том, что современные технологии и прежде всего вычислительные машины резко сократили период разработки товаров или услуг, тем самым еще более увеличивая возможность потенциального предложения. Эта причина также делает практически все рынки и сектора экономики более динамичными.
Однако помимо внешних существуют и внутренние причины, вызывающие необходимость постоянных, кардинальных изменений. Как ни странно, для крупных организаций они, может быть, более значимы. Любая организация (особенно крупный банк), даже если в момент своего основания она была построена по самой оптимальной схеме, через некоторое время утрачивает исходную оптимальность, приобретает функциональную и тактическую несогласованность, нелогичность, непрозрачность. Производственные процессы запутываются, происходит отклонение от основных изначальных ориентиров и приоритетов деятельности, ослабевает мотивация и т.п.
И все это может происходить по причинам не столько внешним, сколько внутренним. Этот феномен известен многим практикующим менеджерам. Причины могут варьироваться в зависимости от особенностей организации, но, как правило, они кроются в несовершенстве исполнителей, а именно: в субъективности их восприятия, привыкании к определенным негативным явлениям, сложности применения теоретических принципов к конкретным человеческим отношениям, банальной текучести кадров и приоритете личных интересов.
Все это приводит к постепенной деформации базисных принципов и ориентиров, отходу от оптимальности, нарастанию стихийности развития и в конечном итоге, если так можно выразиться, к "мутации" системы управления и организации в целом.
За рубежом считается, что любая организация не реже какого-либо определенного периода (в зависимости от своих размеров и особенностей - например, раз в семь лет) должна производить на основе детального анализа текущей ситуации полную реорганизацию (реинжиниринг) своей деятельности. Программа таких изменений может включать различные направления преобразований (реструктуризация, построение новой концепции взаимоотношений, мотивации и менеджмента, смена и/или переквалификация части специалистов, стратегическая переориентация, модернизация технологической и информационной базы, реинжиниринг основных и вспомогательных бизнес-процессов, системы управления в соответствии со стратегическими целями и т.д.).
Все вышесказанное объясняет острую необходимость постоянных изменений, актуальность которых в российских условиях еще выше, так как в отличие от зарубежных стран, где все эти глобальные изменения хотя и происходили стремительно, но все-таки не в течение десяти лет, как это было у нас.
Общий подход: теория и практика
Но вывод о необходимости постоянных изменений не является панацеей от возникновения новых и новых проблем. Каким образом сделать так, чтобы необходимые изменения были не только осознаны и теоретически сформулированы менеджментом, но и практически реализованы? Тут скрываются наиболее серьезные трудности.
Очень часто бывает, что какие-то изменения очевидны, более того, уже обсуждены и даже "приняты" руководством, но тем не менее либо внедряются так долго, что теряют актуальность, либо вообще не внедряются. Тому есть разные причины. Во-первых, это консерватизм людей, привычка к текущей ситуации и даже боязнь, нежелание каких-либо изменений. Все это весьма часто встречается именно в крупных организациях. Во-вторых, несоответствие или даже противоположность интересов разных групп людей внутри крупной организации, возникающих из-за нежелания делиться полномочиями, ограничивать свою власть, брать на себя больше ответственности; это также может быть просто страх существенного сокращения численности своего подразделения. Практика показывает, что внедрение чего-то нового в подразделении влечет за собой существенное сокращение. Это одна из самых сложных управленческих задач, однако решать ее все-таки приходится.
С теоретической точки зрения управление изменениями (Change Management) - это отдельный и не менее сложный, чем разработка самих изменений, вопрос. Существует множество разнообразных научных теорий, направленных на решение данной задачи. Одной из наиболее простых и в то же время часто используемых на практике является теория, предложенная американским ученым-психологом Куртом Левином.
Согласно Левину для управления какими-либо изменениями или преобразованиями чрезвычайно важно понимать природу изменений и их восприятие, их отражение в человеческой психике. Несмотря на то что теория Левина возникла в 40-х годах XX века, она до сих пор считается одним из базовых подходов в управлении изменениями. По концепции Левина для правильного внедрения какого-либо изменения необходимо пройти три стадии: "размораживание", "движение" и "замораживание". Основная идея заключается в том, что при создании изменений обязательно необходимы, помимо собственно преобразований, подготовительная стадия и стадия закрепления результатов.
Подготовительная стадия, или "размораживание", ставит своей основной целью сделать текущее положение еще хуже и невыносимее, довести его до абсурда. Таким образом сознательно развивается ощущение необходимости перемен и их неотвратимости у всех заинтересованных лиц. Кроме того, эта стадия предполагает активизацию деятельности по различным направлениям, связанным с объектом изменений, причем без каких-либо определенных целей, кроме как "расшевелить улей". Все это приводит к тому, что объект (коллектив кредитной организации) вступает в стадию психологической готовности к предстоящим изменениям.
Стадия "движения" предполагает проведение всех запланированных изменений и естественное в этих условиях преодоление препятствий. При этом Левин советует относиться к изменениям именно как к "движению". Необходимо соблюдать определенные и известные участникам преобразований правила, четко понимать не только цель движения, но и маршрут, не стараться двигаться чересчур быстро, другими словами, "не превышать скорости".
Последняя и, возможно, наиболее важная стадия - "замораживание" - ставит целью сделать осуществленные изменения необратимыми, то есть закрепить (или "заморозить") их. Эта стадия особенно важна, так как на практике часто даже после успешного осуществления преобразования ситуация постепенно может обращаться вспять. Это связано с тем, что первое время для объекта изменений (человека или группы людей) его предыдущее состояние по-прежнему является более естественным, знакомым, и по нему может возникать своеобразная "ностальгия". Поэтому, чтобы не произошло "плавного отхода назад", новое состояние необходимо зафиксировать, или "заморозить". Это достигается разными способами, к которым можно отнести средства мотивации как психологического, так и материального плана, разъяснение преимуществ текущей ситуации, обеспечение видения перспектив и новых возможностей.
Рассмотрев вопросы снятия психологических противоречий при проведении изменений, необходимо остановиться и на основных практических подходах к решению задачи управления изменениями при проведении преобразований в кредитных организациях. Рассмотрим, каким образом при возникновении проблем в банках решалась на практике задача внедрения изменений.
Первый возможный подход заключается в централизованном и жестком управлении всеми изменениями со стороны высшего руководства. Для этого, например, в банке вводится постоянная штатная единица - заместитель председателя правления по развитию. Очень важен и принципиален для этого подхода именно высокий уровень лица, ответственного за развитие и изменения, так как в процессе внедрения изменений постоянно возникает необходимость решать множество вопросов, и именно бесконечные согласования и обсуждения способны затормозить любой процесс. Вследствие этого человеку, ответственному за процесс развития банка, необходимы существенные полномочия для принятия решений и контроля исполнения, включая доступ к процессу материального стимулирования сотрудников без дополнительных согласований.
При этом никакая текущая работа, кроме управления изменениями и развитием, не должна входить в обязанности такого руководителя, поскольку данная работа требует очень больших усилий и напряжения и практически всегда связана с решением конфликтных ситуаций. Ответственность данного руководителя в этом случае будет полностью распространяться на все преобразования, и если они не будут осуществлены, значит он не справился со своей работой.
Подобного рода руководителю напрямую должны подчиняться некоторые организационные структуры, с помощью которых он сможет осуществлять аналитическую обработку информации, быструю и грамотную подготовку необходимых материалов, описание и моделирование бизнес-процессов с помощью современного инструментария, анализ правовых аспектов нововведений и их экономического эффекта. Такой подход к управлению изменениями достаточно часто встречается в зарубежных банках. В России некоторые кредитные организации стараются его использовать, и на практике он достаточно эффективен.
Второй подход основывается на том, что в большинстве случаев причиной невозможности практического внедрения каких-то изменений является наличие различных интересов у разных групп исполнителей, руководителей или подразделений. Что удобно одним, кажется неудобным и даже опасным другим. Поэтому для проведения преобразований необходимо в первую очередь снять подобные противоречия и противоположность интересов внутри организации (в большей степени это касается крупных организаций).
Этого можно достичь, например, на основе создания межфункциональных групп. В кредитной организации создается (на постоянной основе или под конкретный проект) группа менеджеров и специалистов, участвующих в осуществлении тех или иных банковских процессов. Группа формируется из наиболее авторитетных и творчески мыслящих представителей всех подразделений, которым доверяют остальные сотрудники и которые выступают одновременно экспертами и защитниками интересов своих групп. Руководство банка наделяет эту группу (комитет) достаточно высокими полномочиями по управлению изменениями. Внутри группы вводится система стимулирования ее участников в зависимости не от осуществления их функциональных обязанностей, а от практической реализации проекта, чтобы снять противоречия интересов. Потенциальный финансовый интерес участников должен быть существенно выше их текущих доходов, чтобы компенсировать возможную потерю ими административных позиций, а также чтобы избежать разногласия внутри группы. При этом другие специалисты и менеджеры банка, не входящие в эту группу, весьма сплоченную вследствие единства и сопряженности целей, не смогут существенно ей противодействовать, и необходимые изменения будут достаточно быстро и активно внедряться в практику.
Третий подход заключается в признании банком невозможности или высокой сложности самостоятельного управления изменениями и активном привлечении для решения этой задачи (в рамках конкретных проектов) сторонних организаций, в первую очередь специализированных консалтинговых и технологических компаний. В этом случае часть полномочий по решению оперативных вопросов и контролю ведения проекта передается внешним консультантам.
Такой подход имеет свои положительные стороны. Во-первых, ответственность за реализацию проектов также возлагается на стороннюю организацию, и оплата ее услуг может находиться в полной зависимости от практического внедрения каких-либо изменений. Во-вторых, такие организации имеют практический опыт решения подобных проблем и застрахованы в отличие от банка от типичных ошибок и промахов.
Разумеется, перечень предлагаемых подходов к решению рассматриваемых проблем не является исчерпывающим, тем не менее они дают представление о практически проверенных способах управления изменениями и решении сложной задачи внедрения нововведений, совершенствования технологии и системы функционирования организации в целом.
Рассмотрим, каким образом должно производиться внесение изменений или полная реорганизация какого-либо банковского бизнес-процесса с точки зрения последовательности или порядка работ. Основные этапы можно сформулировать следующим образом:
- определение объектов изменений и их "размораживание";
- документирование текущей технологии работы и классификация бизнес-процессов;
- выработка критериев оптимизации и определение ограничивающих условий;
- анализ текущей технологии работы;
- выработка, согласование и документирование новой технологии;
- внедрение изменений;
- контроль эффективности осуществленных преобразований;
- корректировка и закрепление изменений. Теперь рассмотрим детально каждый из этих этапов.
Определение объектов изменений и их "размораживание"
Сначала следует выявить первостепенные объекты изменений. Необходимо в первую очередь браться за те направления преобразований, которые могут дать наибольший экономический эффект. С другой стороны, выбор первого объекта должен определяться наличием достаточно высоких шансов на успех, чтобы не выработалось устойчивое противодействие к преобразованиям в организации... И самое главное - не браться за все сразу. Это, как известно, приводит к тому, что не будет сделано ничего.
Также необходимо помнить о наличии подготовительной стадии (о которой говорилось выше, когда мы рассматривали теорию управления изменениями Левина).
Помимо этого, в рамках подготовительной стадии целесообразно заранее определить еще один момент. Учитывая особенности работ по реорганизации, необходимо заранее определить нормы защиты информации, которые будут способствовать свободному и беспрепятственному общению сотрудников организации с группой, осуществляющей изменения. Это необходимая мера, поскольку по необъяснимым причинам многие сотрудники слишком беспокоятся за сохранность и неразглашение информации, не являющейся конфиденциальной.
На подготовительной стадии также необходимо решить вопрос о финансировании работ по исследованию и подготовке к преобразованиям, так как они для своего выполнения потребуют определенных ресурсов, людских и денежных, потому что, даже если организация и не использует привлеченных специалистов, она обязательно должна разработать и внедрить систему дополнительной мотивации и поощрения сотрудников, непосредственно работающих над изменениями.
Документирование текущей технологии
Прежде чем начать основную работу по преобразованиям, следует тщательно изучить положение дел и детально описать процесс "как есть". Такое описание необходимо по многим причинам. Оно будет служить информационной базой для анализа и выработки преобразований, станет источником информации для экспертов, не знакомых с деталями технологии работы организации. Опираясь на данное описание, можно будет восстановить прежнюю практику работы в случае неудачных изменений. Таким образом, описание процесса "как есть" будет носителем знания и реальной практики работы и тем самым сможет защитить организацию.
Но для всех этих целей необходимо, чтобы описание было крайне точным и детальным. И здесь появляется проблема номер один при моделировании технологии работы - противоречие между требуемой детальностью описания и экономической эффективностью этого процесса. Совершенно очевидно, что чем точнее и детальнее описание, тем больше оно требует усилий, времени, ресурсов и, следовательно, существенно дороже. Практика показывает, что затраты на такое моделирование могут находиться в диапазоне от нескольких тысяч до сотен тысяч долларов. Поэтому необходимо находить компромисс, не забывая, что само по себе моделирование деятельности, без связи с преобразованиями, не имеет практически никакой стоимости.
Большинством экспертов признается, что подобное описание целесообразно осуществлять в графическом виде, например в виде SADT-диаграмм (вопросы методологии будут рассмотрены отдельно) с использованием современного программного инструментария в виде CASE-средств. Можно использовать как статические, так и динамические средства моделирования бизнес-процессов, в том числе основанные на других методологиях и стандартах. Выбор их следует осуществлять, исходя из необходимого уровня наглядности схем и предполагаемых сроков разработки таких схем, так как более сложные и наглядные средства моделирования бизнес-процессов подразумевают более сложный и дорогой процесс их оформления. В любом случае самые простые средства моделирования настолько доступны, что можно настоятельно рекомендовать не использовать собственные или недостаточно известные стандарты.
Цель такой работы заключается в создании там, где это необходимо, графического и текстового описания рассматриваемых процессов для дальнейших анализа, контроля и выработки рекомендаций по реорганизации.
Сбор требуемой информации осуществляется на основании регламентирующих документов банка, анкетирования и информации, полученной от сотрудников банка в результате личных бесед. Круг лиц, проводящих опрос, в зависимости от выбранной схемы управления изменениями может состоять из представителей специализированного подразделения, межфункциональной группы или внешних консультантов.
Опросить целесообразно всех сотрудников банка, кроме работников служб охраны, хозяйственного и технического обеспечения, водителей и секретарей. Категорически не рекомендуется опираться на информацию только руководителей подразделений, так как на практике они почти всегда стремятся приукрасить ситуацию и будут рассказывать не о том, как они работают, а о том, как должны или хотят работать. Другой интересный феномен, связанный со сбором информации по технологии работы, - достаточно высокая степень некорректности информации. Опять же практика показывает, что и рядовые исполнители очень часто склонны к искажению информации или ее неточной передаче. Поэтому все собранные данные необходимо тщательно проверять, сопоставляя информацию из различных источников или наблюдая непосредственно за работой специалистов.
Собранная информация поступает на обработку, которая включает следующие этапы:
* создание общей структурной модели банка (по подразделениям), а также модели предлагаемых услуг и обеспечивающих процессов в банке. Глубина данных моделей - сотрудник банка (главный бухгалтер, операционный работник отдела и т.д.) и услуга или процесс банка (расчетно-кассовое обслуживание, уплата налогов). Формулировка миссии, целей, задач и выполняемых функций подразделений банка;
* классификация и описание целей и задач бизнес-процессов, примеры которых приводились выше;
* описание и моделирование бизнес-процессов, определенных в предыдущем этапе. Глубина моделей - операции, выполняемые сотрудниками, документы и состояния документов (заполнить договор, подписать документ, расходный ордер, подтвержденный расходный ордер);
* обсуждение полноты и правильности построенной модели. Корректировка модели;
* разработка дополнительных аналитических документов или описаний (в зависимости от необходимости).
Далее мы рассмотрим, как формируются документы, необходимые для разработки программного обеспечения: функциональные и технические задания и спецификации (многие из преобразований требуют изменений или полной замены информационных систем организации).
Самым недорогим и в то же время достаточно эффективным для преобразований на уровне средних по размеру организаций является построение бизнес-моделей в форме блок-схем в соответствии со стандартом IDEF0 с использованием, например, программного продукта BPWIN*(6), вид интерфейса которого изображен на рис. 15.
"Рис. 15. Интерфейс программного продукта BPWIN"
Дополнительные описания являются приложениями к соответствующим схемам и включаются в файл модели в формате BPWIN, а в случае больших объемов представляются в формате документов MS WORD. При необходимости (и после предварительного согласования) можно дополнить бизнес-модель организации документами, выполненными в других форматах.
В построенной модели для среднего банка могут рассматриваться около 15-20 бизнес-процессов. Общий объем документации, описывающей технологию работы банка, - от 350 до 1000 страниц диаграмм и текста.
Критерии оптимизации и ограничивающие условия
Прежде чем приступить к анализу текущей ситуации и преобразованиям, необходимо четко обозначить критерии оптимизации и произвести ранжирование с точки зрения их значимости. Имеет смысл установить для каждого из критериев весовой коэффициент. Критерии зависят от текущего состояния кредитной организации и стратегических приоритетов в ее развитии. Базовыми критериями к разработке оптимизированной модели являются:
- снижение временных затрат на реализацию бизнес-процессов организации или выполнение отдельных операций;
- снижение стоимости предоставляемых услуг и обслуживающих процессов;
- повышение контролируемости деятельности организации на всех уровнях;
- масштабируемость или наращиваемость технологии и ее гибкость на предмет организации новых услуг и изменение под воздействием внешних факторов (законодательство или экономические обстоятельства);
- изменение соотношения между прямыми и косвенными затратами на реализацию бизнес-процессов организации;
- соответствие предлагаемых решений текущему законодательству и регламентирующим документам;
- повышение качества обслуживания клиентов;
- расширение спектра или увеличение объема операций.
Те или иные критерии для различных банков имеют разное значение. Так, например, сокращение расходов для некоторых из них может быть не так актуально, как увеличение скорости обслуживания.
Анализ текущей технологии работы
После того как бизнес-процесс детально исследован и "зарисован", определены объекты и цели или критерии оптимизации, естественно, должна наступить стадия его анализа и выработки основных направлений концепции его реорганизации. В рамках данного блока могут существовать следующие этапы:
* выявление и анализ операций, не добавляющих стоимости с точки зрения клиента;
* анализ данных с целью выявления однотипных операций в различных процессах, оценка возможности их объединения или исключения;
* анализ возможного видоизменения процессов. Рассматриваются варианты изменения документопотоков исходя из регламентированных условий. Строятся альтернативные модели бизнес-процессов или их отдельные составляющие в тех же стандартах, что и основная модель. Производится их описание, описание необходимых изменений и затрат на переход;
* поиск путей автоматизации отдельных операций. Рассматривается возможность использования компьютерных средств для автоматизации операций, сокращения трудозатрат исполнителей, упрощения операции. Производится оценка затрат и ожидаемого эффекта. Данный этап проводится совместно со службами, ответственными за автоматизацию;
* оценка стоимости каждой операции в масштабах банка. Оценочная стоимость операции включается в ее описание. Оценку операции можно проводить по следующим параметрам: длительность выполнения, количество и периодичность, ежедневные затраты ресурсов (переменные издержки), постоянные издержки, общие материальные затраты;
* анализ сложных операций с целью их разукрупнения и упрощения;
* анализ неоказываемых услуг и возможности предоставления их клиентам. Оценка действий, необходимых для этого, и ожидаемый экономический и маркетинговый эффект;
* сравнительный анализ текущих услуг и практики их осуществления в других банках с целью возможного повышения качества обслуживания и корректировки тарифной политики.
Направления анализа выбираются в зависимости от критериев оптимизации и объекта изменений.
Выработка, согласование и документирование новой технологии
Полученные идеи и результаты первичного обследования являются основой разработки новой технологии. Она осуществляется в несколько стадий.
Вначале определяется концепция потенциальных изменений. Предложения, поступившие в ходе предыдущих стадий, тщательно обсуждаются и оцениваются с точки зрения эффективности их внедрения. Поиск такой концепции - один из сложнейших моментов реинжиниринга, так как является во многом творческой работой. Отчасти поэтому, отчасти потому, что этому вопросу посвящено достаточно публикаций и внимания, в том числе со стороны прародителей теории реинжиниринга, мы не будем уделять ему отдельное внимание.
После выработки и согласования со всеми заинтересованными сторонами и высшим руководством концепции преобразований необходимо приступить к разработке новой технологии или технологической схемы "Как должно быть", описывающей все детали будущей технологии. Инструментальные средства разработки обеих схем "Как есть" и "Как должно быть" должны быть идентичны. Необходимость такого описания связана с невозможностью внедрения чего-то абстрактного, необходимостью проведения переобучения специалистов и т.д.
На основании концептуальной модели определяется порядок взаимодействия между подразделениями. Проводится наложение бизнес-процессов предоставления услуг на предлагаемую схему работы. Определяются регламентирующие документы и нормативные акты, управляющие рассматриваемыми процессами.
Далее производится заключительная детализация модели до элементарных бизнес-операций и технологических решений по их реализации. Параллельно производится корректировка модели в соответствии с возможностями ее реализации и техническими возможностями.
Модель "Как должно быть" также проходит несколько стадий согласований и после этого подлежит утверждению высшим руководством банка.
После описания перспективной технологии, ее корректировки и окончательного утверждения во всех деталях необходимо разработать детальный план внедрения новой технологии с распределением сроков, контрольных точек и ответственных лиц. Такой план может содержать следующие пункты:
* разработка новых должностных инструкций в соответствии с измененными обязанностями исполнителей;
* корректировка учетной политики банка, других внутренних регламентов;
* обучение сотрудников новой технологии;
* прием экзаменов по результатам обучения;
* разработка или настройка программного обеспечения и т.д.;
* запуск новой технологии в опытную эксплуатацию;
* переход на полное промышленное использование новой технологии.
Все эти процедуры должны быть по возможности распараллелены и сопряжены по срокам для меньшей затраты времени на реализацию проекта в целом. Для представления сложных громоздких проектов и осуществления контроля за ними удобно использовать современные инструментальные средства управления проектами.
Достаточно простым примером такого средства может служить программный продут компании Microsoft - MS Project. Этот продукт позволяет автоматизировать распределение ресурсов, контроль выполнения отдельных этапов проекта и связанных задач, общее планирование. Он обладает возможностями планирования и распределения людских ресурсов, мониторинга нагрузок, построения сетевых графиков и Гант-диаграмм, гибкой системой отчетных форм, а также многими другими возможностями. Данный программный продукт в конечном счете облегчает непростую задачу управления проектами с десятками и даже сотнями подзадач, большинство из которых связаны различным образом с другими работами и большим количеством исполнителей. Внешний вид интерфейса данного программного продукта представлен на рис. 16.
"Рис. 16. Вид интерфейса программного продукта Microsoft Project"
He менее важно заранее составить и утвердить бюджет преобразований, в котором будут запланированы все расходы, связанные с реализацией плана реинжиниринга. С учетом того что подавляющее число подобных проектов не укладываются в первоначальный бюджет и испытывают нехватку ресурсов, необходимо заранее на стадии бюджетного планирования заложить специальный резерв в размере 20-25% для покрытия возможных перерасходов.
Контроль эффективности осуществленных преобразований
После начала полного использования новой технологии необходимо произвести оценку эффективности проделанных изменений. При этом, если реальный эффект существенно ниже запланированного, не стоит расстраиваться, так как эта ситуация достаточно типична. Даже если после контрольного анализа осуществленных преобразований окажется, что эффективность их крайне низка или даже стремится к нулю, то есть только окупаются затраты, - это уже хорошо, и такие преобразования должны быть признаны положительными, и их имеет смысл продолжать.
Не стоит при этом забывать о таких следствиях, которые невозможно посчитать в денежном выражении, но которые приносят важные стратегические выгоды. Речь идет об общей активизации деятельности организации, создании у работников и менеджмента ощущения перспективы, дополнительной мотивации, росте интереса к организации со стороны и т.д.
Корректировка и закрепление изменений
На основании данных по реальной эффективности, а также результатов промышленной эксплуатации бывает необходимо осуществить корректировки в деятельности или внедренной технологии. Такие корректировки представляют собой незначительные изменения и возникают вследствие того, что решить все вопросы сразу практически невозможно. Относительно закрепления, или "замораживания", модифицированного процесса уже говорилось выше.
Рассмотрев общие вопросы управления изменениями, настало время вернуться к области информационных технологий и рассмотреть организацию проектной работы, которая, как мы уже отмечали, является логичным продолжением проектов преобразований внутри организации и своей главной целью имеет практическую реализацию механизмов развития бизнеса.
Сразу стоит оговориться, что практику проектной работы мы будем рассматривать на основе проекта замены основной информационной системы банка, как и в первой части книги, где мы уже рассматривали работу по подбору решений на этом же примере. Это связано с тем, что это направление является одним из самых объемных и сложных в ИТ. Но все сказанное ниже будет актуально и для других ИТ-проектов, таких, как развитие интернет-услуг, замена компьютерного оборудования, автоматизация новых филиалов и т.п.
Иногда кажется, что не существует причины, по которой бы организация, имеющая уверенно работающие структуры, стабильную, удовлетворяющую текущим требованиям информационную систему, решилась бы на дорогостоящий проект замены своей информационной базы. Более того, основная часть сотрудников и руководства полагает, что, купив и успешно внедрив у себя однажды то или иное информационное решение, организация навсегда закрыла для себя эту проблему.
Но жизнь опровергает подобное заблуждение. Независимо от типа организации, программного и аппаратного обеспечения, квалификации сотрудников каждый раз повторяется один и тот же сценарий жизни программного приложения. Он длится в среднем 10-15 лет, а при стремительном изменении внешней среды, как это было в последние годы у нас, - 5-7 лет. В течение этого времени программное обеспечение многократно дорабатывается, адаптируясь к новым условиям. Появляется большое количество различных дополнительных решений, реализованных вне рамок системы. При этом решения разрабатываются различными людьми, при полном отсутствии каких-либо стандартов и документации. Потом возникает необходимость установления связей между этими доработками, и количество проблем, требующих решения, возрастает многократно, становясь нерешаемыми.
В результате возникает ситуация, когда небольшое ядро, некогда являвшееся современной и перспективной системой, обрастает неконтролируемым множеством утилит и заплаток. Простое увольнение одного из программистов (средний срок работы программиста в кредитной организации 3-5 лет) приводит к полной переработке целой области информационных задач. Надежность, защищенность подобной системы не удовлетворяет никаким требованиям. И отсутствие проблем со службой безопасности объясняется только тем, что в России службы безопасности очень редко занимаются анализом программного обеспечения в банке. Любое изменение в правилах учета и обработки информации все сложнее реализуется в установленные сроки. Даже если компания-разработчик своевременно предоставляет все доработки, служба автоматизации банка не успевает своевременно адаптировать свои решения к новым условиям.
Попытка решить данную задачу приводит к тому, что менеджеры организации начинают обращать внимание на новые разработки, появляющиеся на рынке, и после очередной проблемы с устаревшей информационной системой принимают решения о покупке новой, которая, по их мнению, снимет большую часть проблем.
Однако выделенные деньги и поддержка руководства не гарантируют того, что проект будет удачным. Он может быть вообще нереализован. По данным ряда зарубежных консалтинговых агентств, около 20% проектов не внедряются. Хотя, если проект будет реализован, скорее всего затраты на него будут существенно выше ожидаемых. По тем же данным, только 16% проектов реализуются в соответствии с первоначальными планами, а затраты на реализацию остальных в среднем в 1,8 раза выше утвержденных бюджетом.
Рассмотрим, какие шаги придется выполнить организации, чтобы минимизировать потери и увеличить шанс успешного завершения проекта. Мы уже останавливались на особенностях проектной работы в самой первой главе, где проектный подход рассматривался как один из ключевых подходов к организации ИТ-службы банка. Но настало время остановиться на этом и рассмотреть отличия проектной и традиционной форм организации работы. Прежде всего нам необходимо определиться с тем, что же такое проект. Мы будем опираться на широко распространенную за рубежом методику управления проектами РМВОК 2000.
Итак, как правило, проекты направлены на выполнение каких-либо вполне определенных задач, связанных с достижением стратегических целей организации. Это происходит потому, что стратегические цели не могут быть достигнуты посредством текущей деятельности, они требуют создания изменений, а средство создания изменений - это проект.
Проекты обычно связаны с новой, уникальной и не повторяющейся или редко повторяющейся работой в отличие от обычной деятельности, которая носит регулярный характер. Поэтому они всегда носят временный характер, ограничены четкими временными раками, операционная же работа является преимущественно постоянной.
Согласно упомянутой выше методике проект - это любая деятельность, ограниченная во времени и направленная на создание уникального нового продукта, услуги или на достижение другой цели. Деятельность, ограниченная во времени, означает, что каждый проект имеет четко обозначенные начало и конец. Проекты осуществляются на всех уровнях организации, в них могут участвовать от нескольких человек до сотен людей.
Примеры проектов:
* разработка новой услуги;
* внутренние организационные изменения;
* реинжиниринг бизнес-процессов;
* разработка и внедрение новой информационной системы;
* внедрение новой бизнес-практики или процесса;
* развитие филиальной сети;
* техническое перевооружение;
* создание позитивного рыночного имиджа.
Общим между проектной и традиционной операционной организацией работ является то, что они выполняться людьми, используют ограниченные ресурсы, планируются и контролируются менеджментом.
Первым шагом любого проект является определение его истинной цели. Необходимо, чтобы каждый участник четко понимал, почему организация вкладывает в проект огромные деньги вместо того, чтобы потратить их на зарплату или выплаты акционерам, какие преимущества по отношению к текущему состоянию он получит по завершению проекта. Только в этом случае участники проекта будут выступать единой командой, и шанс на его успешную реализацию существенно возрастет.
Следующим шагом является определение области проекта. Четкое ограничение рабочей области позволит существенно сократить время на обсуждение и согласование проекта.
После того как определены цель и область проекта, можно перейти к более детальной его проработке и описать условия выполнения. Результатом этого этапа (для нашего примера - замены информационной системы) должны стать ответы на следующие вопросы:
* Какой видится идеальная система? В данном ответе необходимо собрать описания идеальной системы от различных подразделений и определить набор параметров, которым она должна соответствовать.
* Какие параметры системы критичны и их значения? В продолжение предыдущего вопроса необходимо помимо идеальных значений определить минимально допустимые параметры.
* На каком ядре должна базироваться система? Ответ на этот вопрос может дать служба автоматизации на основе имеющегося опыта, наличии системных специалистов и уже имеющихся программно-аппаратных решений. Следует помнить, что, например, смена системы управления базами данных может стоить столько же, сколько и весь остальной проект.
* Каков общий бюджет проекта и каковы максимально допустимые затраты? Это разные величины, определяемые оптимистичным и пессимистичным прогнозами. Различаться на практике, исходя из предоставленных ранее данных, они могут в среднем в 2 раза, а иногда и более. При этом рекомендуется сначала определить максимально допустимую сумму и после этого переходить к сумме бюджета.
Результатом первичного анализа должно быть повторное решение о начале проекта. Учитывая, что первичный анализ не приводит к существенным затратам, принятие решения о временном отказе от проекта не будет психологической проблемой. При принятии повторного решения рекомендуется ответить на все те вопросы, которые уже рассматривались нами в главе "Выбор решений".
Возможно, обдумав все проблемы, которые возникнут при проекте, руководство банка примет решение повременить с его началом. Но если решение не изменилось, то начинается следующий этап.
Для того чтобы решить задачи, направленные на достижение цели проекта, необходимо создать команду проекта под управлением менеджера проекта. При этом речь идет именно о команде со всеми ее признаками: у всех одна цель, хотя каждый имеет свои задачи, все принимают участие в решении важных вопросов, бюрократия сокращена до абсолютного минимума, все подчинено достижению цели, любые поощрения даются всем участникам проекта и только за достижение цели, неформальным лидером команды является самый опытный в решении текущего вопроса, члены команды консультируют друг друга.
Данный подход позволит консолидировать усилия и знания всех участников проекта. К сожалению, в большом количестве организаций объединить сотрудников подобным образом достаточно сложно. Часто различие в статусе подразделений настолько велико, что добиться полного сотрудничества кажется невозможным. Но тем не менее это необходимо.
Преодолеть это можно путем повышения статуса менеджера проекта. Хорошо, если его ранг будет уровня заместителя председателя банка. В этом случае различия между рядовыми участниками не будут казаться столь значительными, чтобы мешать работе. Для иллюстрации рассмотрим два примера.
Первый вариант. Руководитель проекта - начальник отдела автоматизации. Участники команды: сотрудник бухгалтерии (не самый опытный, поскольку самый опытный - главный бухгалтер - не может подчиняться начальнику отдела по статусу), сотрудники отдела автоматизации, казначей (человек, отвечающий за расходы), сотрудник фронт-офиса (тоже не руководитель). При такой организации в проектной группе образуются отношения, изображенные на рис. 17.
Второй вариант. Руководитель проекта - вице-президент банка. Участники команды: главный бухгалтер, начальник отдела автоматизации, казначей (человек, отвечающий за расходы), руководитель фронт-офиса. Отношения в проектной группе при такой организации изображены на рис. 18.
Как видно из схем, если руководитель проекта по статусу стоит выше всех остальных участников команды, имеющийся человеческий потенциал организации используется максимально эффективно. Это приводит к решению большей части задач с минимальным объемом затрат или совсем без них.
"Рис. 17. Схема взаимодействия при руководстве проектом (вариант 1)"
Стоит оговориться, что менеджер проекта может обладать высоким статусом, достаточным для решения всех задач, и не являясь членом правления организации. Так, он может иметь этот статус благодаря своим знаниям и опыту, то есть быть авторитетным экспертом организации или приглашенным со стороны менеджером. Причем этот последний вариант интересен тем, что при этом достигается очень важная составляющая - менеджер является независимым.
Постоянные работники организации слишком подвержены внутренним политическим и социальным отношениям, чтобы быть беспристрастными и профессиональными в полном объеме. Поэтому иногда их действия сложно объяснить. Они могут знать, что и как нужно сделать, но по определенным личным причинам не хотеть этого. Так, часто из-за боязни обнародования неудачи внутренние менеджеры стремятся затягивать проекты на годы, при этом обстоятельно аргументируя свою позицию, прикрываясь нуждами пользователей и необходимостью сделать все в лучшем виде.
"Рис. 18. Схема взаимодействия при руководстве проектом (вариантом 2)"
Особенно стоит обратить внимание на передачу ответственности за проектные затраты казначею. Вариантом такого решения может быть установка лимита затрат на проект с последующим премированием частью сэкономленных денег всех участников проекта. Другой приемлемый вариант - сосредоточение всех финансовых вопросов в руках менеджера проекта. В обоих случаях казначей будет выполнять также роль контролера всех затрат и роль аналитика, их оптимизирующего.
Несмотря на то что вклад руководителя проекта огромен, это ни в коем случае не умаляет роли самой команды. И здесь необходимо отметить несколько моментов. Команда должна подбираться исходя из социальной совместимости ее членов. Плюс к этому участники проекта должны уметь и любить работать в команде. Это умение может значить больше, чем собственный профессионализм, так как польза от задач, выполненных большим профессионалом-одиночкой, меньше, чем потенциальный вред для проекта от разрозненности, несогласованности, отсутствия единого подхода и тяги к нововведениям и изысканиям лучшего решения. Следующий важный аспект подбора команды состоит в том, чтобы оптимально подобрать команду единомышленников, которые при этом будут обладать максимально различными знаниями и умениями. Это связано с тем, что (в нашем примере в процессе смены информационной системы банка) во время реализации проекта всегда будут возникать сложные задачи из смежных областей, и тогда наличие в команде людей с разными знаниями и возможностями позволит решать максимально широкий объем задач без потери времени на поиск нужного специалиста или совета со стороны.
Отдельной темой является наличие времени у участников проекта для его выполнения. Любая деятельность во внерабочее время связана с дополнительными затратами, прямыми или косвенными. Грамотный руководитель проекта сведет такие работы к минимуму или откажется от них вовсе. Хорошим инструментом в поиске свободного времени является поденный месячный график выполняемых задач в течение месяца, а также почасовой график выполняемых задач за день (табл. 14). Для большинства специалистов кредитной организации данные графики неравномерны: там есть и пики, и периоды затишья, которые и являются временным резервом проекта. В общем использование резерва является бесплатным для организации. Иногда следует выполнить ряд работ, как правило, связанных с автоматизацией бизнес-процессов, для увеличения свободного рабочего времени. Автоматизация каких работ дает наибольший эффект, видно из построенных временных графиков (рис. 19).
В любом случае контроль за выполняемыми работами и за загруженностью участников проекта является одной из основных задач руководителя проекта, который должен стремиться к максимально оптимальному распределению задач исходя из особенностей каждого работника, плана проекта и их критичности.
Пример таблицы ежедневной занятости специалистов
┌────────────┬───────────┬──────────┬────────────┬────────────┬────────────┬─────────┬────────┬────────┐
│ Сотрудник │ 9-10 │ 10-11 │ 11-12 │ 12-13 │ 14-15 │ 15-16 │ 16-17 │ 17-18 │
├────────────┼───────────┼──────────┴────────────┴────────────┼────────────┼─────────┴────────┴────────┤
│Специалист │Ожидание │Обслуживание клиентов │Обработка │Ожидание │
│операционно-│(30 мин).│ │документов. │ │
│го зала │Подготовка │ │Контроль и│ │
│ │выписок │ │подготовка к│ │
│ │клиенту │ │отправке │ │
├────────────┼───────────┼──────────┬────────────┬────────────┼────────────┼─────────┬─────────────────┤
│Экономист │Ожидание │Оформление│Формирование│Оформление │Ожидание │Контроль │Ожидание │
│бухгалтерии │ │входящих │документов и│собственных │ │отправки │ │
│ │ │платежей │отчетов │платежей │ │платежей │ │
│ │ │ │закрытия дня│банка │ │ │ │
├────────────┼───────────┼──────────┼────────────┼────────────┴────────────┼─────────┼─────────────────┤
│Специалист │Прием │Ожидание │Закрытие дня│Ожидание │Отправка │Ожидание │
│отдела │информации │ │в АБС │ │платежей │ │
│автоматиза- │из РКЦ.│ │ │ │ │ │
│ции │Печать │ │ │ │ │ │
│ │выписок по│ │ │ │ │ │
│ │счетам │ │ │ │ │ │
└────────────┴───────────┴──────────┴────────────┴─────────────────────────┴─────────┴─────────────────┘
"Рис. 19. Пример графика ежедневной занятости специалиста"
Обычно необходимость предпроектного обследования не вызывает сомнения. Если компания-разработчик объявляет его частью работ по внедрению, то отказать ей в этом невозможно, в противном случае с разработчика будет снята вся ответственность за возникающие проблемы. Если же для помощи приглашены сторонние консультанты, то предпроектное обследование и разработка на их основе перспективной схемы работы организации, а также плана перехода являются объектом их работы.
Однако результаты предпроектного обследования могут существенно различаться в зависимости от того, кто и по каким методикам его проводит. Результатами наиболее полного предпроектного обследования должны быть следующие документы:
* описание текущей деятельности организации и информационной системы. Данное описание становится более наглядным и полезным, если выполнено в графическом формате с текстовыми пояснительными записками;
* перечень документов, участвующих в документообороте, их состояние и печатные формы;
* альбом отчетности, формируемой в организации;
* перспективная модель организации после реструктуризации информационной системы, включая оптимизированную систему документооборота. Также необходимо провести полную экономическую оценку проекта;
* подробный план перехода от текущей модели к перспективной с указанием ресурсов, сроков и исполнителей;
* список доработок информационной системы, утвержденный к внедрению.
Учитывая большой объем предстоящих работ и необходимость проверенных методик для проведения подобного обследования, наиболее логично поручить их либо консалтинговым компаниям, либо специализированному подразделению компании-разработчика.
В ряде случаев можно обойтись сокращенным предпроектным обследованием. Это так называемая двухшаговая реализация проекта. Первый шаг - простая смена ядра системы без расширения функционала и оптимизации документооборота, второй шаг - реализация новых требований на уже работающем новом ядре. Данный подход более стабилен и снижает угрозу работоспособности организации в целом, однако требует большего времени. В этом случае в качестве предпроектного обследования достаточно описания текущего функционала информационной системы. Обследование может быть выполнено либо сотрудниками компании-разработчика, либо сотрудниками кредитной организации.
Несмотря на то что предпроектное обследование требует определенных финансовых затрат, по его результатам рекомендуется сделать дополнительное подтверждение решения о начале реализации проекта с учетом нового понимания объема работ, скорректированного бюджета и ожидаемого эффекта. Обоснованный отказ от проекта на данном этапе будет понят как акционерами, так и высшем руководством. Отказ от проекта на последующих этапах будет означать его провал и, как следствие, санкции для менеджеров и исполнителей.
Одним из важнейших результатов предпроектного обследования, независимо от выбранного сценария, должен стать план проекта, который настолько важен, что ему будет посвящена отдельная глава.
План работ строится на основе согласованного сторонами списка задач. Поэтому, прежде чем составлять план, они должны быть подготовлены. Обычно это происходит на той же стадии предпроектного обследования. Естественно, учесть все аспекты еще только начатых работ, их глубину и реальную трудоемкость невозможно, но тем не менее план проекта в первом приближении может и должен быть составлен именно на этой стадии. Впоследствии он будет расширяться, детализироваться, возможно, пересматриваться, но это не отрицает необходимости его наличия и согласования с самого начала проекта.
При составлении плана работ почти все участники проекта стремятся, чтобы их участие было как можно меньше. Исключением могут являться некоторые сотрудники отдела автоматизации, которые хотят, чтобы работа была как можно более интересной, желательно с решением "сложных" задач, объемной разработкой новых программ и покупкой оборудования. Как правило, эти люди контролируемы, но о них не стоит забывать. С другой стороны, и пользователи, заказчики зачастую пытаются автоматизировать операции, автоматизация которых не имеет никакого смысла, например операцию, которая возникает раз в полгода.
Реалистичность объема проектных задач и сроков - это первый экзамен, который должен успешно сдать менеджер проекта при начале работ и закрепить его в плане проекта. Самое легкое - отвечать на все предложения: "Мы это сделаем и очень скоро", ведь проект только начинается. Но ответственный руководитель проекта должен быть пессимистом, учитывать опыт других проектов и очень реалистично оценивать имеющиеся силы и ресурсы и уметь говорить "нет", аргументируя свою позицию. Менеджер проекта, видя перед собой постоянно основную цель проекта, должен уметь находить компромисс и убеждать все стороны.
Как же может быть сокращен и адекватно оценен объем требований? Основным приемом снижения объемов работ является поиск работающих прототипов. Если требуются новые отчеты при расчете налогов, надо выяснить, нет ли аналогичных отчетов в других областях. Если требуется организация новой услуги, надо посмотреть, как она реализована в других банках. А если ее там нет, то еще раз проанализировать ее необходимость.
Общий алгоритм поиска прототипа заключается в следующем. Сначала идет поиск аналогов решения всей задачи. Если их нет, то формулируется более общая задача и ищутся подобные решения. И так до тех пор, пока не будет найдено ближайшее по смыслу работающее решение. Затем определяются доработки к нему. Например, если нужна система межфилиальных расчетов, за основу можно взять систему расчетов в РКЦ или SWIFT, или систему "банк-клиент". Всегда есть аналогичные системы, доработка которых существенно дешевле и надежнее, чем разработка системы с нуля. Кроме того, если в приведенном примере система расчетов будет создаваться на базе системы "банк-клиент", то побочным эффектом будет расширение предлагаемого клиентам сервиса.
Другой универсальный механизм оценки адекватности требований и оправданности их автоматизации - это финансовая оценка. По каждой потенциальной задаче руководителем проекта может быть сделана оценка требуемого времени специалистов, учтены все необходимые другие ресурсы и в конечном счете получена оценка стоимости выполнения этой отдельной задачи. Она должна быть сравнима со стоимостью поддержки данной операции в "ручном" или полуавтоматическом режиме. Не очень умно автоматизировать получение отчета, затраты на ручное выполнение которого в десятки раз ниже стоимости доработки системы. Окончательное суждение в подобных вопросах должно принадлежать представителям бизнеса.
Рассмотрим теперь технические вопросы составления самого плана проекта. Самая лучшая формула, которой можно при этом руководствоваться, - это "Плохой план проекта сегодня лучше, чем хороший завтра". Многие руководители проектов пишут планы месяцами, они составляют десятки страниц. Но, к сожалению, их никак не могут дописать и согласовать. План может быть объемным, но 2-3-страничный план, особенно на начальных стадиях, не только является допустимым, но и более предпочтительным.
Из того, что обязательно должно быть в плане, - это ключевые точки (обучение, согласование детальных требований, презентация и корректировка прототипа, завершение разработки, начало и конец тестирования, исправление замечаний, начало и окончание пользовательского тестирования, дополнительное обучение, начало опытной эксплуатации, переход на промышленную эксплуатацию) с точным указанием времени их наступления. Также в плане должны найти свое отражение перечень основных задач и их взаимозависимость, распределение задач по этапам, ресурсное обеспечение и ответственные лица. Если все это есть и согласовано со всеми сторонами, то план достигает своей цели.
Ниже представлен пример планов проекта, выполненных в традиционном виде с помощью специального программного продукта MS Project, и более простой вариант плана проекта, подготовленный с использованием MS Excel (рис. 20 и 21).
"Рис. 20. План проекта в виде Гант-диаграммы, подготовленный в MS Project"
Следующий этап - детальная постановка задачи. Корректная постановка задачи - уже повышение вероятности успеха и сокращение затрат на проект на 30-50%. Четкие ответы на вопрос "Что надо?" часто сразу дают ответ на вопрос "Как делать?". Особенностью российских правил учета является тот факт, что изменения в них часто носят весьма глобальный характер, в результате четкого понимания всех изменений на этапе начала проекта нет ни у кого в организации. Для решения этой проблемы используются приемы, которые рассмотрены ниже.
Описание глобальной цели проекта включает ответы на вопросы "Зачем?" как для внешней среды (Зачем ЦБ РФ издал такую инструкцию?), так и самой организации и ее подразделений (Зачем организации реализовывать этот проект?). Вариантов ответов на последний вопрос может быть несколько: "Чтобы организацию не оштрафовали" (самый неудачный ответ), "Данная инструкция позволит снизить операционные риски от совершения операций" и т.д. Анализ ответов позволит не только более точно понимать детали изменений, но и прогнозировать дальнейшие дополнения и исправления.
"Рис. 21. Упрощенный план-график проекта"
Создание единого информационного пространства проекта. В простейшем варианте оно представляет собой директорию, в которой все участники проекта записывают имеющуюся у них информацию и соображения по поводу решаемой задачи. Более сложным вариантом является организация интранет-конференции.
Использование ролевого моделирования процесса подразумевает обыгрывание несколько раз бизнес-процесса всеми его участниками с обязательной регистрацией всех выполняемых действий и пожеланий:
┌────────────────────────┐ ┌─────────────────────────────┐
│Сотрудник бухгалтерии: │ │Сотрудник отдел отчетности: │
│Я регистрирую документ│ │Я формирую отчет группировки│
│данного типа в АБС.│ │платежей по статьям расхода│
│Ввожу следующие поля: │ │за период. В качестве│
│СЧЕТ ПО ДЕБЕТУ, СЧЕТ ПО│ │параметра отчета я должен│
│КРЕДИТУ, СУММУ,│ │определять интервал дат.│
│НАЗНАЧЕНИЕ... │ │Отчет должен иметь следующую│
│ │ │форму: │
│ │ │ │
│Пометка: надо вводить│ │┌────┬─────┬────┬─────┬─────┐│
│еще и статьи расхода....│ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │└────┴─────┴────┴─────┴─────┘│
└────────────────────────┘ └─────────────────────────────┘
Данный прием моделирования позволяет максимально использовать имеющийся человеческий капитал, поскольку каждый участник строит свой бизнес-процесс самостоятельно, а общий контроль осуществляет руководитель и представители других подразделений.
Описанные приемы помогут группе более точно понять и написать техническое и бизнес-задание проекта. В бизнес-задании описываются основные функциональные требования, техническое - отражает более детальную информацию, особенности, включая параметры и подходы к реализации. Иногда они подготавливаются разными людьми, но гораздо чаще представляют единый документ, который готовится одним человеком - аналитиком. Далее мы не будем делать различий между этими документами и понятиями.
Следует помнить, что, если точного задания не получится, придется давать системе, реализующей проект, дополнительную гибкость. Но реализация универсальной, гибкой бизнес-функции требует в несколько раз больше ресурсов на разработку и сопровождение, чем статичное решение.
Кроме того, рекомендуется вести разработку двух заданий, которые условно можно назвать: "Программа-минимум" и "Программа-максимум". В первом варианте нужно описать минимальные изменения в организации по сравнению с текущим положением дел, достаточные для реализации основной цели. Второй документ должен составляться с учетом всех пожеланий и перспектив. Как правило, в конце проекта будет реализован некоторый промежуточный вариант. Имея установленный проект бюджета, группа сначала реализует только самые необходимые требования (на это бюджета, как правило, хватает), а потом либо будет дополнять данное решение новыми возможностями, либо аргументирует прекращение работ и возьмет на себя ответственность за это.
В любом случае при постановке задачи, как и везде, вредны крайности. Многие проекты были загублены чересчур грамотными аналитиками, которые месяцами составляли задания, исчисляемые сотнями страниц. Потом сами же с трудом могли понять, что они имели в виду, настолько запутана и сложна была задача или ее описание. Поверхностность также вредна. Исходя из практического опыта, можно сказать, что ориентирами "золотой середины" могут являться параметры объема работ по подготовке технического задания, представленные в табл. 15.
Ресурсы и объем работ по подготовке технического задания
┌────────────┬────────────────────┬───────────────────┬─────────────────┐
│Размер банка│ Количество │Примерное время для│ Примерный │
│ │ выделенных для │завершения этапа с │ суммарный объем │
│ │ постановки задачи │учетом согласований│ задания в │
│ │ аналитиков │ │ страницах, с │
│ │ │ │ учетом │
│ │ │ │ комментариев │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Небольшой │ 2-3 │ 1-2 месяца │ 100-150 │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Средний │ 4-5 │ 3 месяца │ 200-300 │
├────────────┼────────────────────┼───────────────────┼─────────────────┤
│Крупный │ 6-8 │ 4-5 месяцев │ 350-500 │
└────────────┴────────────────────┴───────────────────┴─────────────────┘
Вне зависимости от модели организации работы на проекте и степени вовлеченности внешних консультантов в проект с самого начала необходимо организовать регулярное и эффективное взаимодействие проекта с высшим руководством организации. Это позволит облегчить принятие требуемых решений, будет способствовать повышению статуса проекта, явится источником дополнительной мотивации и повышения ответственности участников проекта. Реализация такого взаимодействия обычно происходит в следующих формах.
Проектный комитет - орган управления проекта, который должен состоять из представителей высшего менеджмента организации, бизнес-менеджмента и менеджера проекта. Он должен периодически собираться для принятия и утверждения самых важных решений по ходу проекта. Периодичность зависит от фазы проекта, но в целом это не должно происходить реже, чем раз в месяц. Менеджер проекта докладывает комитету об основных результатах работы, текущем состоянии проекта, основных проблемах, принятых решениях, ситуациях, требующих решения комитета и выходящих за компетенцию менеджера. В процессе заседания комитета ведется протокол, который затем предоставляется всем участникам и заинтересованным лицам и является официальным документом для банка, проекта и подрядчиков.
Спонсорство - важный элемент проекта. Для проекта должен быть назначен спонсор (куратор), лицо из высшего руководства, один из членов проектного комитета, обычно близкий бизнес-подразделениям, который будет более активно взаимодействовать с менеджером проекта для помощи и консультирования. Он должен быть представителем руководства, уполномоченным принимать любые решения, который будет больше всех других высших менеджеров организации в курсе хода проекта и его проблем. Обычно это человек, который выступал инициатором проекта среди руководства или поддерживал его с самого начала.
Периодическая отчетность. Руководитель проекта должен готовить для информирования всех заинтересованных сторон о ходе работ специальные отчетные формы. Периодичность их зависит также от состояния проекта, но в общем должна быть чаще, чем заседания проектного комитета. Может быть рекомендована следующая схема. Если проект испытывает сложности, имеет место срыв сроков, недостаток бюджета и т.п., то отчетность должна предоставляться еженедельно. Если проблемы у проекта есть, но не очень значительные, отчетность составляется раз в две недели. И если у проекта нет каких-либо проблем, способных повлиять на срок, бюджет, то раз в месяц. В отчетах должен быть в удобной форме отражен текущий статус проекта, этап и его фаза, основные ближайшие контрольные точки, выполненный по сравнению с предыдущим отчетом объем работ, достижения проекта за период, основные риски, проблемы, действия по их минимизации и решения, открытые вопросы, прогноз по выполнению сроков и бюджета.
Задачей разработки программного обеспечения является построение систем, отвечающих требованиям бизнеса и обеспечивающих максимум преимуществ от их использования. В то же время эти системы должны создаваться с учетом их дальнейшего сопровождения, требований к производительности и качеству. Организация, осознавая всю важность использования информационных технологий, ставит перед собой цель создать базу для разработки и внедрения программного обеспечения, отвечающего вышеуказанным задачам.
Данная глава описывает основные требования к разработке программного обеспечения как собственными разработчиками, так и с использованием сторонних организаций. Кроме того, в ней определены обязательные этапы при создании и внедрении программных продуктов, требования к документированию каждой стадии и контролю качества продукта. Тестирование и внедрение, являясь составными частями разработки, будут рассмотрены в специально выделенных для этого главах. В настоящей главе мы не будем делать различий между разработкой программного обеспечения, его модификацией, доработкой и настройкой. Мы будем считать, что все перечисленные подходы входят в понятие разработки, являясь методами ее технического осуществления.
Итак, каковы основные участники процесса разработки?
Заказчик - подразделение организации, у которого возникла необходимость в разработке нового или изменении существующего программного обеспечения. Также в качестве заказчика может выступать организация в целом.
Разработчик - проектная команда, сформированная на основе службы ИТ или сторонней организации, непосредственно работающая над разработкой, изменением и внедрением программного обеспечения.
Контролеры - сотрудники организации (кроме непосредственно разработчиков), осуществляющие наблюдение за созданием продукта. Контролерами могут выступать начальники подразделений или назначаемые ими сотрудники подразделения. Если заказчиком является организация, то контролеры назначаются руководством. Для больших проектов, важных для бизнеса, возможно привлечение в качестве контролеров сторонних консультантов.
Аналитики - специалисты в области банковских технологий, участвующие в постановке задачи и консультировании всех сторон в ходе проекта.
Одним из первых важнейших требований является документирование всех этапов процесса разработки программного обеспечения, начиная с постановки первоначальных требований и заканчивая вводом в эксплуатацию и дальнейшим сопровождением. Документы, возникающие в процессе разработки, такие, как спецификации, планы разработки, руководство пользователя, являются неотъемлемой частью программного продукта. Заказчик вместе с программным продуктом должен по возможности получать всю документацию, связанную с разработкой продукта. Документирование процесса разработки ведется с целью облегчения процесса сопровождения, доработки и контроля качества продукта. В случае смены разработчика проектная документация должна обеспечить дальнейшую эффективную работу с программным продуктом.
Качество документации должно отвечать следующим критериям:
* правильность:
- соответствие (трассируемость) требований и спецификаций соответствующей системе, и наоборот;
- последовательность в описании требований, спецификаций и функций;
* полнота:
- использование версий и дат документов для контроля изменений, доступность всех версий документов (в том числе рабочих);
- функциональность системы должна быть максимально полно описана в системных требованиях;
- документация должна предоставлять информацию для всех категорий пользователей, операторов системы и разработчиков;
* удобство и простота использования:
- использование оглавлений, алфавитных указателей, глоссариев и кросс-ссылок;
- логическая последовательность и непротиворечивость в использовании терминологии;
- уместный внешний вид документации (шрифты, формат).
В то же время необходимо, как уже отмечалось, избегать излишней бюрократизации, другими словами - в зависимости от цели проекта набор, состав и объем документов должен меняться.
Применительно к исходным кодам программ, которые по сути являются документацией к системе, также должны во многом выполняться вышеуказанные требования. Исходные коды разработанных для банка систем (как силами собственных программистов, так и сторонними организациями) должны по возможности предоставляться вместе с системой и документацией к ней. Это условие необходимо включать в договора на разработку программного обеспечения и в служебные инструкции разработчиков. Исходные коды должны содержать комментарии в количестве, необходимом для понимания структуры исходного кода и функциональности каждого модуля, подпрограммы или класса. Код программы должен писаться с учетом дальнейшего сопровождения и возможного расширения функциональности системы.
Программный код должен быть отформатирован в едином стиле. В общем случае утвержденные и используемыми всеми разработчиками стандарты кодирования содержат следующие составляющие:
* принципы форматирования программного кода, включая использование структурированного расположения текста и отступов между строками кода для удобства считывания. Комментарии в коде должны давать краткое описание функциональности программ, модулей, классов, методов класса и т.п., а также описывать формат и назначение входных и выходных данных;
* соглашения о стиле программирования должны, в частности, описывать стандарты именования переменных, констант, классов и т.д. Должен применяться общий подход к использованию внутренних переменных, констант и структур данных (таких, как массивы). Все это поможет созданию предсказуемого и легко читаемого кода, с которым было бы несложно работать как на этапе разработки, так и в ходе модификации и дальнейшего сопровождения; приемы написания эффективного кода. Эти правила могут быть связаны с использованием эффективных структур данных и алгоритмов, созданием максимально производительных запросов к базам данных и т.п.
Представители заказчика обязаны принимать участие и контролировать процесс разработки на всех этапах. Должны быть назначены представители заказчика (подразделения организации или выделенные эксперты), отвечающие за разработку, - контролеры. Это могут быть сотрудники банка, знающие в деталях бизнес-процессы, для поддержки которых создается система, сотрудники службы информационных технологий или сторонние консультанты. Для максимальной отдачи от внедрения разрабатываемых систем крайне необходимо тесное взаимодействие с разработчиками.
Ответственность за разработку систем помимо назначенных сотрудников или консультантов несут соответствующие руководители подразделений или организации в целом.
Оценка эффективности разработки
Масштаб и степень следования стандартам разработки программного обеспечения могут зависеть от размера и характера проекта, а также от того, какие инструменты разработки используются. Для небольших, некритичных для бизнеса приложений необходимость строгого следования стандартам может быть не так важна. Однако для больших и чувствительных с точки зрения бизнеса проектов, где велика стоимость разработки и появляются большие риски, необходимы максимальный контроль за процессом разработки и следование стандартам программирования.
В любом случае затраты и усилия, потраченные на разработку, должны соответствовать уровню решаемых с помощью системы проблем. Стоимость проекта должна оцениваться с точки зрения его важности и выгоды от использования разработанной системы.
Целью разработки новых систем и модификации существующих является повышение эффективности бизнес-процессов, поэтому помимо разработки программного обеспечения необходимо параллельно рассмотреть другие варианты мер, влияющих на эффективность организации (дополнительное обучение сотрудников, реорганизация подразделений, незначительное изменение или всеобъемлющий реинжиниринг бизнес-процессов с привлечением сторонних консультантов и т.п.). Эта проблема очень важна, и поэтому она будет детально рассмотрена в рамках главы "Управление изменениями".
Процесс разработки программного обеспечения должен содержать этапы инициации (организации) проекта, оценки проекта, анализа и проектирования, конструирования и внедрения системы.
Этап инициации проекта, с точки зрения разработчика, должен включать подготовку заказчиком требований к новой системе, описание ее функций и структуры, оправдание ее с точки зрения бизнеса и получение одобрения со стороны руководства для того, чтобы приступить к следующим этапам разработки. Если заказчиком выступает подразделение организации, необходимо одобрение руководителя подразделения, если заказчик - организация в целом, то руководителей организации.
Первоначальные требования к системе направляются, как правило, в ИТ-подразделение, которое оценивает факторы, критичные для успеха проекта и его качества. Необходимо выяснить, насколько проект согласуется с общей стратегией банка в области развития бизнеса и использования информационных технологий, приблизительно оценить общие затраты на проект, а также каким образом и кем должен осуществляться контроль над проектом.
Оценка проекта и его согласование были рассмотрены выше, поэтому мы здесь лишь упомянем о них.
В направлении дальнейшей детализации необходимо выбрать несколько вариантов реализации программного обеспечения и точно оценить стоимость каждого варианта, трудности, связанные с его осуществлением, время на осуществление, программные средства и инструменты, необходимые для проекта, исполнителей проекта, а также преимущества каждого варианта. Кроме того, требуется описать недостатки существующей системы и как они будут устранены при внедрении нового программного обеспечения. В итоговую оценку необходимо включить меры по изменению бизнес-процессов и структуры организации, которые сопровождают внедрение системы. Детальную оценку проекта осуществляет ИТ (проектная команда), заказчик выбирает окончательный вариант решения. Итоговый документ должен быть подписан заказчиком и проектным руководством, руководителем ИТ.
Этап анализа и прогнозирования включает в себя разработку проектной документации, в деталях описывающей работу будущей системы, ее структуру, технические и программные средства, необходимые для ее функционирования. Этот этап важен для облегчения дальнейшей работы над системой.
Итогом данного этапа должны явиться одна или несколько спецификаций системы, которые готовятся разработчиком при поддержке заказчика. Мы уже отмечали, что для наших целей не будем различать различные типы спецификаций. Отметим лишь, что вне зависимости от их названия они должны содержать:
* описание бизнеса (бизнес-процессы и функции, которые будут автоматизированы):
- детальное описание существующих бизнес-процессов и каким образом они будут затронуты при внедрении системы;
- детальное описание новых бизнес-процессов, которые будут созданы или получены при изменении существующих;
- описание мер контроля, которые будут внедрены в новой системе;
описание программно-аппаратного обеспечения, необходимого для функционирования системы:
- операционная система(ы), которая будет использоваться;
- сетевая среда, оборудование и протоколы;
- средства разработки новой системы;
- средства защиты информации;
- как новые платформы будут включены в существующую информационную инфраструктуру;
* спецификация функциональности системы:
- общее описание функциональности системы как в повествовательной форме, так и в виде диаграмм;
- разбиение системы на модули;
- соответствие модулей бизнес-требованиям к системе. Должно быть описано, каким требованиям отвечает каждый модуль. Все бизнес-требования должны покрываться модулями системы;
- модель данных, используемая в системе (диаграмма "сущность- связь" или аналогичные). Функциональность, вынесенная в серверную часть системы;
- описание того, каким образом будут реализованы требования к информационной безопасности, производительности и надежности системы;
- детальное описание интерфейсов с другими системами;
- список разрабатываемых программ (включая вспомогательные) и параметры для их запуска;
- список ошибок и предупреждений, генерируемых системой;
- спецификация должна быть четко структурированной и содержать оглавление, алфавитные указатели, глоссарий и список используемых терминов.
Все спецификационные документы подписывает разработчик и предоставляет для ознакомления заказчику.
Написание подробных спецификаций (постановку задачи) можно заменить использованием методики создания прототипов. При этом прогрессивном методе используется итерационный подход. Описание будущей системы производится через согласование интерфейсов пользователя с системой. С будущими пользователями системы обсуждаются и утверждаются экранные формы, соответствующие различным функциям системы. Вместе с внешним видом этих форм описываются соответствующие им входные и выходные данные. Другими словами, время на подготовку документов практически не тратится, пользователь рассказывает, что ему нужно, разработчик создает модель и презентует ее пользователю, который высказывает свои замечания и т.д., пока решение (или по крайней мере его внешний вид) не согласовывается. Выгодой этого подхода являются меньшие сроки разработки системы, следовательно, меньшие затраты на разработку.
Решение об использовании методики создания прототипов принимается до начала этапа анализа и проектирования, на этапе выбора варианта реализации системы. При принятии решения должны быть оценены следующие риски:
* рамки проекта могут быть значительно расширены без формального одобрения, так как пользователи системы могут добавлять "полезные" с их точки зрения функции;
* прототипы описывают только интерфейсы пользователей, и такие вопросы, как информационная безопасность, могут быть упущены на этапе проектирования;
* не для всех компонент системы можно создать прототипы;
* использование прототипов не так детально описывает разрабатываемую систему, как написание спецификаций. Следствием могут явиться трудности с поддержкой и сопровождением в долгосрочной перспективе, а также недостаточный уровень тестирования каждого модуля.
На этапе конструирования формально описанные требования к системе, созданные на стадии анализа и проектирования, преобразуются в рабочую систему. Разработка включает в себя создание структуры программы, кодирование, создание структуры базы данных и тестирование на уровне модулей системы, системы в целом и интерфейсов с внешними приложениями.
Система должна согласовываться с формальными требованиями к ней. В случае внесения существенных изменений в систему, не описанных в проектной документации, эти изменения должны быть согласованы с заказчиком и внесены в спецификации.
Программное обеспечение разрабатывается с использованием структурного подхода, при этом должны соблюдаться ранее установленные стандарты кодирования. Исходные коды содержат комментарии в количестве, необходимом для понимания структуры исходного кода и ее функциональности. Следует максимально снизить риски, возникающие при смене разработчиков.
Программный код должен быть составлен на основе уже упоминавшихся стандартов. Разработчик при этом использует систему контроля версий исходных кодов. При внесении изменений в исходный код описывается, какие изменения и с какой целью вносились.
Разрабатываемое программное обеспечение тщательно тестируется (методика тестирования будет рассмотрена подробно в следующей главе). Должен быть разработан план тестирования, который включает этапы тестирования модулей системы, системы в целом, интерфейсов с внешними программами, интерфейсов пользователя, тестирование систем безопасности и надежности системы. Согласно этому плану необходимо разработать набор тестов, которые помимо покрытия функциональных требований к системе (тестирования по методу "черного ящика") покрывали бы внутреннюю структуру исходного кода (покрытие условных переходов, метод "белого ящика").
Тестовая среда, база данных и исполняемые модули должны быть отделены от рабочей системы. Разработчики не должны иметь доступ к рабочей системе после ее внедрения и запуска.
Результаты тестирования должны быть зафиксированы, в случае обнаружения ошибок они исправляются разработчиком, и это должно быть отображено в отчете по тестированию. Результаты тестирования - найденные ошибки и как они были исправлены - должны быть подписаны разработчиком и предоставлены заказчику.
На этапе конструирования разработчик разрабатывает документацию для пользователей и администраторов системы в электронном и бумажном виде. Документация должна иметь надлежащую структуру, содержание, формат и внешний вид.
Должны быть разработаны программы учебных курсов и соответствующие учебные материалы, которые учитывают специфику всех категорий пользователей и администраторов системы.
В случае необходимости могут быть описаны дополнительные меры, необходимые для внедрения системы. Например, установка нового оборудования, перепланировка используемых помещений, изменения в структуре организации и обязанностях сотрудников, описание необходимых административных процедур и т.д.
На этапе внедрения, особенности которого также будут рассмотрены в отдельной главе, разработанная система должна быть установлена на серверы и рабочие станции, подготовлена и передана заказчику документация, проведено обучение пользователей и администраторов системы. На этой стадии система окончательно принимается заказчиком.
Заказчик должен убедиться, что документация является полной, подготовлена согласно принятым стандартам и покрывает требования к системе. Учебные курсы должны полностью покрывать функциональные возможности системы и отвечать запросам различных групп пользователей и администраторов. Все пользователи и администраторы, перед тем как начать работу с системой, проходят соответствующие курсы.
Заказчику необходимо убедиться, что установка нового программного обеспечения не повлияет на данные уже работающих систем. При переносе данных из старой системы необходимо протестировать, что данные перенесены правильно и полно. Результаты переноса утверждаются заказчиком.
Заказчик составляет план приемки программного обеспечения, разрабатывает набор тестов для проверки функциональности системы и проводит тестирование в соответствии с планом. Кроме того, ему необходимо убедиться в том, что система установлена правильно и предусмотрены все необходимые меры, связанные с защитой информации и надежной работой системы.
Служба поддержки пользователей организуется силами разработчика или на базе сотрудников заказчика. В отношениях между заказчиком и разработчиком должны быть предусмотрены соглашения об уровне обслуживания, на каких условиях будет производиться сопровождение системы, каким образом будут исправляться ошибки, обнаруженные во время эксплуатации системы, а также гарантийные условия.
Документ о завершении внедрения системы подписывают заказчик и разработчик.
Качество и эффективность внедрения напрямую зависят от интенсивности контроля со стороны заказчика. Однако любую внедренную систему можно улучшить с точки зрения эффективности ее функционирования, удобства работы, производительности и надежности. С этой целью по окончании приемки системы можно провести обзор качества разработки и внедрения, в ходе которого выясняются недостатки и упущения в разработанной системе. Этот обзор проводится с помощью сотрудников банка, компании-разработчика или сторонних консультантов. Результатом обзора может явиться отчет о найденных недостатках, содержащий рекомендации по их устранению.
Тестирование представляет собой процесс оценки системы (или компонента системы) ручным или автоматическим способом с целью проверки соответствия указанным требованиям или выявления различий между ожидаемыми и фактическими результатами. Тестирование также подразумевает использование разработанной программы для обнаружения ошибок. Прохождение тестирования не означает, что система больше не содержит дефектов. Тестирование может выявить наличие проблем, а не доказать их отсутствие.
Тестирующий сотрудник не только пытается обнаружить недостатки, но и проверяет программу в работе, оценивает ее надежность, безопасность и безотказность в эксплуатации. Присутствует также экономический аспект. Для более крупных проектов больший объем тестирования обычно выявляет большее количество ошибок. Когда следует прекратить тестирование и какую степень наличия ошибок следует считать приемлемой? Если количество ошибок не превышает определенной допустимой величины, то программное обеспечение может быть квалифицировано как удовлетворяющее требования пользователей и допущено для эксплуатации. Необходимо помнить, что тестирование предполагает, что требования к системе уже сформулированы и не модифицируются.
"Рис. 22. Разработка программного обеспечения"
Стратегия успешного тестирования начинается с процесса его обсуждения на стадии составления спецификаций требований. Тестирование деталей следует проводить на высоком и низком уровне, причем тестирование должно проводиться сначала разработчиками, а затем конечными пользователями. По мере повышения сложности программного обеспечения увеличивается значение эффективного, хорошо спланированного тестирования.
В зависимости от характера и сложности информационного решения банк будет выбирать объем необходимых процедур тестирования. Процесс тестирования может включать все описанные ниже этапы в случае собственного программного обеспечения и некоторые из этих этапов - в случае покупки готового программного обеспечения.
Тестирование "белый ящик" выполняется с целью обнаружения проблем во внутренней структуре программы. Это требует от проверяющего глубокого знания внутренней структуры и, следовательно, не может быть выполнено обычным пользователем. Общая задача такого тестирования - обеспечить проверку каждого шага по алгоритму программы. Основное преимущество всех типов стратегий тестирования "белый ящик": при тестировании принимается во внимание структура всей программы, что облегчает обнаружение ошибок даже в том случае, когда спецификации программного обеспечения недостаточно определенные или неполные.
Тестирование по блокам заключается в проверке блока отдельно от остальной системы. Обычно блок представляет собой функцию или небольшой набор функций (библиотеки, классы), которые выполняются одним программистом. Основная отличительная характеристика блока состоит в том, что он достаточно небольшой по объему для проведения тщательной проверки, которую можно назвать исчерпывающей. Обычно тестирование "белый ящик" проводится разработчиками. Небольшой размер блоков позволяет обеспечить высокий уровень проверки кодов. Таким образом легче обнаружить и устранить ошибки на данном уровне тестирования.
Одним из наиболее сложных аспектов разработки программного обеспечения являются интеграция и тестирование больших подсистем. Интегрированная система часто дает существенные и необъяснимые сбои, которые трудно устранить. Тестирование в таком случае состоит в проверке нескольких блоков, которые образуют модуль или подсистему. Тестирование интегрированной системы в основном направлено на интерфейс между блоками, что должно гарантировать совместимость блоков и их корректную совместную работу.
Тестирование "черный ящик" состоит в поиске отсутствующих или неправильно выполняемых функций с целью оценки, насколько хорошо программа отвечает требованиям. Функциональные тесты обычно подтверждают правильность данных на вводе и выходе. В этом случае пользователь - идеальный проверяющий. Иногда такое тестирование называют пользовательским. Тест функциональности состоит в том, чтобы проверить правильное выполнение отдельных функций системой. Проверяющие проводят тесты, которые, по их мнению, отражают использование системы в будущем, ее функциональных возможностей.
Системный тест представляет собой более полную версию теста на проверку внешней функции, но в максимально приближенных к "боевым" условиям и среде. При системном тестировании техническая платформа должна быть как можно ближе к фактическим условиям эксплуатации, включая такие факторы, как комплектация оборудования, а также объем и сложность базы данных. В ходе воспроизведения будущих условий эксплуатации системы можно точнее протестировать более сложные черты системы (характеристики, безопасность и безотказность). Однако воспроизводить среду пользователя для системного теста слишком дорого, к тому же может не хватить времени на проведение испытания.
Системное тестирование обычно включает в себя тестирование характеристик, которое выявляет время ответа на запрос, использование памяти, оборудования и время выполнения операции. Тестирование в стрессовой ситуации подводит систему к некоторым пределам для оценки ее возможностей и способности справляться с ошибками. Тесты надежности оценивают реакцию системы на ввод данных, проводят подсчет отказов за определенный период времени с целью оценки или подтверждения степени надежности.
Ретроспективное тестирование представляет собой обязательную проверку, выполняемую на модифицированном программном обеспечении, с целью достижения уверенности в том, что изменения в программу внесены правильно и не оказали отрицательного воздействия на другие компоненты системы.
"Приемо-сдаточное испытание" - это проверка готовой системы группой конечных пользователей с целью окончательного подтверждения готовности системы к работе. В этом случае программа пройдет более реальную проверку, чем на этапе системного тестирования, поскольку пользователи имеют лучшее представление о том, как система будет использоваться.
Рассмотрим некоторые типичные ошибки, совершаемые организациями в результате попыток провести эффективное тестирование программного обеспечения. Эти ошибки можно разбить на 4 категории.
1. Неправильное понимание роли тестирования. Назначение тестирования заключается в обнаружении дефектов продукта. В связи с этим важно хорошо понимать критичность тех или иных дефектов при планировании тестирования, при описании дефектов и подготовке рекомендаций.
2. Недостатки в планировании процесса тестирования. Во многих случаях при планировании тестирования чрезмерное внимание уделяется тестированию функциональности в ущерб тестированию потенциального взаимодействия и системных характеристик. Недостаточное внимание к документации по тестированию и к документации по инсталляции также довольно рискованно.
3. Неправильный подбор персонала для тестирования. Функцию тестирования нельзя поручать младшему персоналу. Группа тестирования должна включать специалистов ИТ по системе и конечных пользователей. Группа тестирования не может действовать эффективно, если ее состав не диверсифицирован.
4. Слабая методика тестирования. Точно так же, как программисты часто предпочитают кодирование написанию алгоритмов, тестирующий персонал часто уделяет чрезмерное внимание самим тестам в ущерб времени, отведенному на составление планов тестирования. Тесты должны дать подтверждение, что программный продукт способен адекватно выполнять свои функции.
Внедрение систем - это комплекс специфицеских задач, выполнение которых позволяет добиться реальной эксплуатации решения в организации. Другими словами, это внедрение изменений, которое мы уже разбирали выше.
В общем случае процесс внедрения состоит из ряда организационных действий, подготовительных работ технического и административного плана, тестовой (опытной) и промышленной эксплуатации. Далее мы рассмотрим эти составляющие.
Внедрение, пожалуй, - самый ответственный момент проекта замены информационной системы. Это связано с рядом причин.
Во-первых, как мы уже отмечали при рассмотрении управления изменениями, это всегда наиболее сложная составляющая работы.
Во-вторых, даже если на предыдущих стадиях была создана очень хорошая информационная система, до тех пор, пока она не внедрена, ее ценность равна нулю. Часто менеджеры стараются до бесконечности совершенствовать продукт, наслаждаясь им в узком кругу программистов и ИТ-экспертов, не понимая, почему ни у кого больше их многолетние изыскания не вызывают оптимизма.
В-третьих, внедрение - это не экзамен, а нечто большее, и поэтому даже блестяще оттестированные и подготовленные системы, сдавшие все "экзамены", могут не подойти по тем или иным причинам. Думать, что заранее можно предвидеть все проблемы, недальновидно. Во время внедрения все проблемы, конфликты, которые не были решены ранее, были забыты или решены неправильно, отложены, недодуманы, скрыты, всплывают практически в один момент, требуя непомерных профессиональных знаний и личных усилий всех участников проекта.
На практике часто бывает так. Внедрение хорошо подготовлено: проведены многочисленные выверки данных, тестирование и многие другие, важные для внедрения, работы (о чем мы еще будем говорить далее). Но почему-то внедрение срывается, ком проблем растет с такой скоростью, что в один прекрасный момент большинству становиться ясно, что система не может быть внедрена. Проектная команда, менеджмент теряют веру, количество проблем от этого возрастает еще больше, и в конечном счете проект останавливается или приостанавливается высшим руководством.
Можно ли избежать этого? Ответ практикующих менеджеров проектов в 99,9% случаев - "да". Набор инструментов для достижения такого результата достаточно уникален и индивидуален и является во многом профессиональным ноу-хау (Know-How) руководителя проекта. Мы же рассмотрим некоторые основные составляющие таких организационных действий, которые позволяют сделать даже проблемное внедрение успешным.
Снятие противоречий и конфликтов. Первый вопрос, который необходимо прояснить, - всем ли нужно внедрение как в самой организации, так и среди подрядчиков? Кому оно невыгодно по тем или иным причинам? Кто против в настоящее время или был против на ранних стадиях проекта? Кто не принимал участия? Даже это может быть важно, потому что успех одного руководителя может автоматически снижать авторитет тех, кто не верил в исход проекта или был против него. Не стоит искать конфликты только среди руководства, они могут быть и на более низком уровне и при этом иметь очень большое значение. Задача руководителя проекта состоит в том, чтобы не только найти все эти центры противоречий и конфликтов, но и свести их на нет или по крайней мере добиться, чтобы их влияние на проект было минимальным.
Прояснение недопониманий и выработка согласованных подходов. Даже там, где нет предпосылок для конфликта, он может возникнуть по причине недопонимания. Внедрение является сложной задачей, и поэтому неминуемо в процессе работ, а особенно на их завершающей стадии, возникают такие ситуации, когда, не решаясь задать лишний вопрос, те или иные участники процесса просто не понимают смысл определенных действий или понимают его неправильно. Задача руководителя проекта - не только добиться того, чтобы количество таких недопониманий было минимальным, его задача также состоит в том, чтобы инициировать процедуры согласования позиций, их обсуждения и понятного и доступного формального закрепления в бумажной форме. Он должен как можно больше задавать вопросов всем участникам, чтобы добиться в конце концов одинаковых и согласованных позиций и полного понимания участниками и заинтересованными сторонами того, что происходит.
Прояснение формальной (юридической) позиции - тоже важная составляющая организационных действий. Выполненная до начала внедрения, посредством дополнительного анализа существующих формальных или договорных отношений между сторонами, она способна оказать реальную помощь в реализации двух предыдущих пунктов. Инициатором этой работы должен выступать руководитель проекта. При выявлении неясностей в формальных отношениях сторон их проясняют обязательно до начала внедрения, чтобы не приостанавливать его или не служить еще одним дополнительным риском.
Онлайн-менеджмент и контроль. Во время внедрения осуществляются постоянный надзор и контроль со стороны высшего менеджмента за происходящим. Он должен быть организован в онлайн-режиме, то есть участники проекта, его руководство имеют приоритетное право на взаимодействие с высшим менеджментом организации. Контроль должен осуществляться на оперативной и регулярной основе. Заседания управляющего комитета должны проводиться чаще, чем при обычной работе, и не реже одного раза в неделю. Не исключен и ежедневный вариант. Формальная отчетность и информация по ходу проекта должна быть доступна всем заинтересованным сторонам также на оперативной основе.
Оперативный анализ рисков. Отдельно руководителем проекта с помощью ведущих экспертов по основным областям ведется анализ рисков внедрения. Его форма должна быть простой и понятной. Это может быть просто текстовый список проблем, где указывается следующая информация: кто инициировал занесение проблемы в список, ее номер (если есть), суть проблемы, ответственный за решение, дата регистрации проблемы, дата решения, кратко основные действия по решению, приоритет и текущий статус (решена или нет). Такой список очень помогает руководителю проекта не забывать обо всех возникающих проблемах и в тоже время является инструментом контроля и давления на исполнителей, ответственных за решение.
Мотивация персонала на достижение результата. Возможно, самый главный пункт - это мотивация всех участников проекта и прежде всего его непосредственных работников на достижение результата. Мы уже останавливались на основных подходах по мотивации, когда рассматривали управление ИТ-персоналом, поэтому не будем здесь повторяться.
Широкое информирование заинтересованных сторон. Отдельная задача в ходе внедрения - информирование всех заинтересованных сторон, включая обычных сотрудников организации, о ходе и статусе работ. При недостатке информирования проект обрастает слухами, которые будут очень мешать в работе. С другой стороны, поддержка со стороны всей организации очень полезна для работы, является дополнительным источником мотивации. Но это возможно только при наличии информации и понимания, в противном случае отношение будет очень негативным.
Качественное и детальное планирование и обеспечение ресурсами. Планирование важно всегда, но на этапе внедрения оно имеет повышенное значение. Помимо этого целесообразно иметь небольшой резерв ресурсов, которые могут быть временно сняты с других работ или привлечены на отдельные участки со стороны. Все стандартные методики управления ресурсами, такие, как сетевое планирование, использование методики критического пути, должны использоваться руководителем проекта для получения информации и оперативного принятия решений по переброске ресурсов или их увеличению.
Существенная часть временных затрат при внедрении систем должна быть потрачена на подготовительные работы технического и административного характера. Данные работы включают:
* доработку программного обеспечения и его тестирование;
* подготовку компьютерной техники, приведение ее к необходимым техническим требованиям разработчика;
* обучение пользователей и администраторов системы;
* разработку конверторов данных из существующей системы в новую, разработку и тестирование методик контроля правильности переноса данных;
* разработку руководств пользователей и администраторов системы;
* разработку инструкций на случай технологических сбоев в системе.
Окончанием подготовительного периода должна стать тестовая эксплуатация системы с участием конечных пользователей. В случае небольших организаций и незначительного документооборота возможна параллельная работа обоих систем. Однако в крупных организациях параллельное ведение - весьма затратное и беспокойное мероприятие. В этом случае лучше применить поэтапное тестирование различных составляющих с участием сотрудников соответствующих подразделений.
По результатам опытной эксплуатации рекомендуется составить акт, в котором регистрируются все недоработки системы, а также сроки их устранения. При этом в случае наличия критичных недостатков, способных привести к технологическому сбою в работе организации, после их устранения необходимо провести повторное тестирование всех составляющих системы. Таким образом, после полнофункционального тестирования до начала рабочей эксплуатации системы вводится мораторий на внесение изменений в систему. Это делается для того, чтобы в результате внесения исправлений не были порождены новые ошибки.
Начало рабочей эксплуатации является самым критическим моментом в проекте. Фактически успешный старт и работа в системе хотя бы в течение нескольких дней означают успех проекта. Конечно, наличие большого количества недоработок, кажущиеся неудобства в работе, периодические сбои не позволяют сказать об этом сразу, но все эти проблемы намного более просты в решении, чем поддержание двух информационных систем и постоянная синхронизация данных в них.
Но начало рабочей эксплуатации и, как следствие, отказ от поддержки старой системы не могут основываться только на желании это сделать. Малейший сбой приводит к откату к предыдущему состоянию, к возврату эксплуатации старой системы, поскольку ни один руководитель не возьмет на себя ответственность продолжать эксперимент, когда, например, у него не проходят обработку клиентские платежи или неправильно рассчитываются процентные ставки по депозитам более чем в течение 10 минут.
В зависимости от размера организации возможны два варианта перехода на рабочую эксплуатацию. Для организации с количеством сотрудников до 100 человек, как правило, применяется тотальный переход. Все пользователи в определенный день (обычно пятницу, чтобы было время для устранения ошибок) начинают работу в новой системе. Основными показателями успешного перехода на новую систему являются отсутствие задержек приема документов у клиента, своевременная отправка платежей, получение правильного баланса.
В случае, если внедряемая система решает большой спектр задач, количество пользователей более 100, необходим поэтапный переход. Он может осуществляться в следующей последовательности:
- запуск интерфейса взаимодействия с внешними платежными системами, маршрутизация платежей филиалов;
- формирование баланса и прочей ежедневной и оперативной отчетности;
- ввод простейших платежных документов в систему пользователями, ведение расчетно-кассового обслуживания;
- учет сложных операций (покупка-продажа валют);
- автоматическое начисление процентов и платы за обслуживание;
- формирование документопотока в соответствии с перспективной моделью организации, изменение обязанностей сотрудников, участвующих в расчетно-кассовом обслуживании клиентов и собственных платежей банка;
- учет операций физических лиц;
- учет внутренних операций банка: расчет зарплат, ведение хозяйственных договоров, учет основных средств;
- учет и ведение кредитов банка;
- учет прочих операций банка, включая торговые операции на бирже. Такая последовательность позволяет минимизировать последствия озможных сбоев и дает время команде внедрения сосредоточиться на одной задаче, а не распылять свои силы на решение всех проблем.
Переход на рабочую эксплуатацию системы обычно заканчивается подписанием акта о проделанной работе. Однако большое количество недоработок и недовольство пользователей нельзя назвать успешным завершением. Таким образом, взаимодействие с разработчиками не заканчивается рабочей эксплуатацией, а переходит в новую стадию - сопровождение. Не стоит требовать от разработчиков немедленного устранения всех недочетов. Лучше в течение некоторого времени дать пользователям поработать с новой системой, почувствовать ее возможности и преимущества перед старой. И только после того, как отрицательные эмоции улягутся и пользователи смогут более квалифицированно говорить о достоинствах и недостатках нового решения, необходимо провести их опрос и составить план устранения действительно важных недоработок. При этом часть проблем к этому времени смогут снять сотрудники автоматизации банка. А остальные решит компания разработчика, которая, получив аргументированные и понятные претензии, не сможет отказать своему клиенту.
Таким образом, система начнет работать в свою полную силу, все больше и больше приближаясь к тому идеалу, о котором думали менеджеры и специалисты банка перед началом проекта, когда рассматривали, каким образом изменить технологию работы банка и какие нововведения ему нужны.
Анализ рисков при реализации проектов
Развитие информационных систем в современном мире требует все больших и больших инвестиций. Затраты современного коммерческого банка на решение информационных задач соизмеримы, а нередко и превосходят все остальные затраты на содержание организации. Поэтому неудачи информационных проектов очень болезненны. Но еще больший ущерб приносят упущенная прибыль, нереализованные услуги, аналитические ошибки.
Несмотря на то что все проекты начинаются с полной уверенности в их реализации и практически все они имеют хорошо разработанные бизнес-планы и достаточные бюджеты, их завершение нередко откладывается на неопределенный срок, а затраты оказываются многократно превышенными.
Мы уже упоминали, что доля неудачных проектов крайне высока. Почему это происходит и кто виноват в подобных ошибках? Наказать и уволить разработчиков и отдельных исполнителей - самое простое решение, однако это не выход, так как потом выясняется, что ошибки продолжают появляться и проект заходит в тупик.
Одной из причин этого явления нередко является отсутствие системы управления рисками. Разрабатываемые планы строятся исходя из идеального течения проекта и постоянства внешних и внутренних условий. При этом исключительные ситуации (например, неожиданные изменения в законодательстве) обычно просто не рассматриваются, не говоря уже о проработке выхода из них.
Данная глава рассматривает методику, позволяющую оценить риски при реализации крупного проекта и минимизировать потери от них. Эта методика была предложена и принята рядом западных компаний и адаптирована к отечественным условиям в результате многочисленных проектов в российских кредитных организациях. Мы уже рассматривали тему управления рисками. Остановимся на этом вопросе еще раз и более детально разберем его с точки зрения проектного управления.
В основе методики управления рисками лежат систематизация, расчет вероятности и ущерба, документирование возможных решений и профилактик, оценка допустимых затрат на профилактику и резерва проекта. Оценка проводится в денежном и временном эквивалентах, так как иногда даже при неограниченном финансовом обеспечении невозможно сделать работы быстрее определенного времени.
Типы рисков в информационном проекте
Первый этап рассматриваемых работ - определение ответственных за различные типы рисков. В зависимости от ответственности за риски их условно можно разделить на три группы.
1. Проектные риски связаны с ошибками в бюджете, графике работ, с проблемами персонала, изменением требований (вызванных как изменением текущих условий проекта, так и желанием заказчика).
К данным рискам можно отнести болезни и увольнение сотрудников, изменения в текущем законодательстве, замену представителя заказчика, контролирующего процесс, изменение мнения заказчика о проекте по ходу его развития.
Ответственным за данный тип рисков исключительных ситуаций является менеджер проекта, способность которого улаживать подобного рода конфликты и определяет его профессиональную подготовку.
2. Технические риски связаны с проблемами реализации технических решений. Основными проблемами здесь обычно являются проблемы разработки (способность разработчиков реализовать ту или иную задачу), неудовлетворительная производительность системы, внедрение и затруднения, связанные с окончательной адаптацией системы под конечных пользователей.
Ответственное лицо за решение подобных проблем - обычно технический руководитель проекта или ведущий аналитик.
3. Бизнес-риски связаны с финансовой поддержкой проекта. Неожиданные сокращения бюджета, вызванные внешними факторами, могут привести не только к сокращению проекта и задач, которые он решает, но и к его полному провалу в случае недостижения главной цели. Для компании-разработчика к данному типу рисков обычно относятся ошибки в оценке рынка данного решения. В российских организациях также к подобного рода нештатным ситуациям относится потеря интереса к проекту со стороны конечных пользователей.
Ответственным лицом в кредитной организации за подобные проблемы может быть заказчик (куратор) проекта или руководитель проектного комитета. Он должен заранее определить приоритеты и организовать резервы для решения приоритетных задач каждого этапа.
Следующим этапом проведения работ по предупреждению рисков в информационном проекте являются разработка их спецификации и системы идентификации, а также вероятностная оценка возникновения внештатных ситуаций, оценка ущерба и расчет резервов для их преодоления. Для компании-разработчика данные расчеты достаточно точны, поскольку большое количество клиентов позволяет сделать выборку для расчета статистических данных с небольшой погрешностью. К сожалению, вероятностные оценки в данных расчетах для коммерческого банка обычно являются весьма условными по причине отсутствия статистики. Для их сбора обычно предлагается набирать статистику по мере развития проекта, рассчитывая ее внутри циклов реализации проектов, а также делать более подробный анализ работ, раннее проводимых в организации. Динамический анализ рисков приведет к постоянной корректировке общих показателей, что затруднит первичное резервирование средств и проведение профилактических работ, однако механизм предупреждения внештатных ситуаций на меньшие сроки остается.
В качестве спецификации возможна разработка менеджером проекта таблицы рисков (табл. 16).
Оформление таблицы рисков проекта
┌───────────────────────┬──────┬─────────┬─────────┬──────────┬─────────┐
│ Наименование риска │ Тип │ Вероят- │Приоритет│ Сумма │Временные│
│ │ │ность, в │ │ущерба, в │потери, в│
│ │ │ % │ │ руб. │ днях │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Увеличение количества│ PS │ 60 │ 3 │ 2 000│ 2 │
│пользователей │ │ │ │ │ │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Изменение выходных│ RE │ 60 │ 2 │ 14 000│ 4 │
│отчетных форм │ │ │ │ │ │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Неподготовленный │ PR │ 30 │ 4 │ 2 000│ без │
│конечный пользователь │ │ │ │ │ затрат │
├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤
│Противодействие │ PR │ 10 │ 2 │ 15 000│ 10 │
│конечных пользователей│ │ │ │ │ │
│внедрению системы │ │ │ │ │ │
└───────────────────────┴──────┴─────────┴─────────┴──────────┴─────────┘
┌───────────────────────────────┐ ┌─────────────────────────────────────┐
│ Расшифровка типов │ │ Приоритеты │
├────┬──────────────────────────┤ ├───┬──────────┬──────────────────────┤
│ PS │изменения размера системы │ │ 1 │Катастрофа│> 100 000 руб. > 20│
├────┼──────────────────────────┤ │ │ │дней │
│ RE │изменения постановки задач│ ├───┼──────────┼──────────────────────┤
├────┼──────────────────────────┤ │ 2 │Критично │> 10 000 руб. > 3 дней│
│ PR │проблемы с персоналом │ ├───┼──────────┼──────────────────────┤
└────┴──────────────────────────┘ │ 3 │Проблема │> 1000 руб. > 1 дня │
├───┼──────────┼──────────────────────┤
│ 4 │Возможно │< 1000 руб. < 1 дня │
│ │игнориро- │ │
│ │вание │ │
└───┴──────────┴──────────────────────┘
По результатам построенной таблицы рассчитываются средние показатели по всем категориям и типам, а также общий ожидаемый ущерб нештатных ситуаций в проекте (табл. 17). Расчеты производятся по следующим формулам:
"Формула 1"
"Формула 2"
Расчет уровня рисков и их влияния
┌───────────────────────────────────────────────────────────────────────┐
│ Итоговая таблица по приоритетам │
├─────────┬─────────────────────┬────────────────────┬──────────────────┤
│Приоритет│ Вероятность, │ Средний денежный │Потери времени, в │
│ │ % │ ущерб, руб. │ днях │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 1 │ 0 │ 0│ 0 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 2 │ 64 │ 9900│ 3,4 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 3 │ 60 │ 1200│ 1 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ 4 │ 30 │ 600│ 0 │
├─────────┴─────────────────────┴────────────────────┴──────────────────┤
│ Итоговая таблица по категориям │
├─────────┬─────────────────────┬────────────────────┬──────────────────┤
│ PR │ 37 │ 2100│ 1 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ RE │ 60 │ 8400│ 2,4 │
├─────────┼─────────────────────┼────────────────────┼──────────────────┤
│ PS │ 60 │ 1200│ 1,2 │
├─────────┴─────────────────────┴────────────────────┴──────────────────┤
│ Общий итог │
├─────────┬─────────────────────┬────────────────────┬──────────────────┤
│ │ │ 11 700│ 4,6 │
└─────────┴─────────────────────┴────────────────────┴──────────────────┘
Результатом данной таблицы является предварительная оценка возможного ущерба от нештатных ситуаций. Данные показатели можно внести в проект в виде страховых резервов времени и денег.
Однако основной задачей данных работ является не столько расчет резерва, сколько снижение затрат и оценка и сравнение затрат на профилактические работы с затратами от ожидаемого ущерба.
Снижение потерь возможно за счет трех действий: профилактики (предотвращения), мониторинга (своевременного распознавания ситуации) и управления критической ситуацией (правильными действиями в случае ее возникновения). Рассмотрим более подробно каждое из них.
Профилактика - некие затраты для устранения, снижения вероятности или снижения ущерба нештатной ситуации. Нередко очень трудно убедить заказчика в дополнительных затратах, особенно если угроза не очень понятна заказчику. Например, достаточно легко получить дополнительное финансирование на дополнительную проработку системы безопасности (угроза несанкционированного доступа), однако нередко очень трудно добиться обучения конечных пользователей, хотя неграмотная эксплуатация также может привести к образованию дыр в системе безопасности. И обычно только хорошо обоснованный документ с оценкой вероятности и значения ущерба может убедить заказчика в правильном распределении средств.
Мониторинг означает разработку системы показателей, определяющих возникновение той или иной проблемы, и механизмов их отслеживания. Своевременное распознавание проблемы нередко позволяет минимизировать потери или свести их к нулю. Например, отслеживание текущего законодательства и своевременное распознавание принципиальных изменений позволят существенно сократить затраты на адаптацию за счет изменений ряда концептуальных решений, таких, как изменение структуры данных или разработка новых алгоритмов. В случае, если время упущено, начинают работать механизмы латания дыр, которые приводят к усложнению системы и, как следствие, росту временных затрат на решения новых задач.
Управление критической ситуацией означает документирование и регламентирование действий в случае возникновения непредвиденной ситуации. Четкое понимание действий менеджером позволяет многократно снизить отрицательный эффект. Предварительное документирование действий позволит скорректировать расчетный эффект ущерба и, как следствие, снизить суммы резервов и сделать проект более привлекательным для инвесторов и заказчиков. Также частью работ по этому направлению может быть создание механизмов смягчения критической ситуации. Например, наличие информации о квалифицированных соискателях на работу в организации будет очень кстати при неожиданном увольнении ключевого работника.
Основой работ по сокращению затрат является разработка плана противодействия рискам проекта. Примером оформления данного плана может служить дальнейшее развитие таблицы рисков (табл. 18).
Оформление плана противодействия рискам
┌─────┬────────┬────────────────┬───────────────┬──────────────┬────────────────┬──────────────────┐
│ N │Вероят- │ Ущерб │ Подробное │ Профилактика │ Механизм │ Что делать │
│ │ ность │ │ описание │ │ мониторинга │ │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 1 │ 40% │2-кратное увел.│Потеря интереса│Максимальная │Постоянное │Попросить │
│ │ │сроков. │у пользователей│популяризация │обсуждение с│руководство │
│ │ │Профилактика = 1│к развитию│проекта, │группой │заказчика отметить│
│ │ │чел/д; │системы из-за│построение │внедрения │подразделения, │
│ │ │эффект Р = 20%; │угрозы │связи между│отношения │обеспечивающие │
│ │ │преодоление =│сокращения │эффектом от│пользователей к│наибольшую │
│ │ │6000 руб./отдел;│ │проекта и│проекту │поддержку проекта.│
│ │ │эффект = Р/2 │ │ростом доходов│ │Рассмотреть │
│ │ │ │ │ │ │исключение │
│ │ │ │ │ │ │сопротивляющихся │
│ │ │ │ │ │ │подразделении из│
│ │ │ │ │ │ │участия в проекте │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 2 │ │ │ │ │ │ │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 3 │ │ │ │ │ │ │
├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤
│ 4 │ │ │ │ │ │ │
└─────┴────────┴────────────────┴───────────────┴──────────────┴────────────────┴──────────────────┘
Из таблицы хорошо виден эффект от контроля за рисками, и этот факт непременно поможет менеджерам максимально контролировать весь проект в целом и более аргументированно отчитываться перед инвестором и заказчиком. Однако необходимо помнить, что управление рисками носит относительный характер и все приведенные цифры в таблице условны и служат для общей оценки нестандартных ситуаций. Также необходимо помнить о динамическом изменении основных показателей проекта, что приводит к постоянному пересчету приводимых ранее величин.
Ожидаемая в следующем году новая волна изменений в правилах бухгалтерского учета приведет российские кредитные организации к необходимости серьезной доработки или смены информационных систем. Безусловно, опыт, полученный банками в области автоматизации за прошедшее десятилетие, позволит существенно сократить потери от изменения правил и механизмов учета. Рассмотрим различные приемы, направленные на сокращение затрат при выполнении различных проектов, связанных с изменениями в текущей деятельности работающей организации.
Одним из самых эффективных путей сокращения проектных издержек является сокращение требуемых ресурсов и использование вместо них уже имеющихся.
К дополнительным ресурсам проекта, то есть тем, на которые необходимы дополнительные затраты, в кредитной организации можно отнести:
* персонал;
* помещение;
* вычислительную технику и программное обеспечение;
* коммуникации.
Как искать человеческие ресурсы для проекта, мы уже говорили. Резервом помещений в банке являются, как правило, переговорные комнаты и комнаты для конференций и заседаний. Но если проект требует долгосрочного использования помещения, то аренды или покупки дополнительного помещения скорее всего не избежать.
Резервом вычислительной техники может являться устаревшее оборудование. Часто в отделах автоматизации скапливаются устаревшие компьютеры и техника. Приведем примеры решения подобных задач.
Временному сотруднику на время проекта требуется компьютер. Можно предложить ему старый компьютер. В 70% случаев этого будет достаточно. Другой вариант: взять компьютер сотрудника, находящегося в отпуске, и заменить жесткий диск. Если сотрудник возвращается из отпуска до завершения проекта, можно переставить данные участника проекта на другой компьютер. Более простой вариант распределенного использования вычислительной техники будет доступен, если в организации для работы используются сетевые диски.
Набор задач, реализуемых на одном мощном сервере, можно разбить и использовать маломощные компьютеры. Например, почтовые и интернет-серверы для небольших рабочих групп могут быть реализованы на устаревших рабочих станциях.
Следует рассмотреть возможность обновления (upgrade) вычислительной техники. Иногда для эффективной работы приложения достаточно просто увеличить объем оперативной памяти, стоимость которой невысока.
В отношении программного обеспечения следует придерживаться позиции противостояния увеличению количества используемых программ. Все задачи надо стараться реализовывать в уже имеющихся приложениях. Особенно это относится к системам управления базами данных. Если банк работает на MS SQL Server, проект должен реализовываться на этой платформе, а не на ORACLE, и наоборот. В противном случае дополнительные затраты возрастут на суммы от $5 до 100 тысяч в зависимости от размеров организации.
Для коммуникаций также существуют некоторые резервы. Как правило, это несанкционированный трафик: от сетевых компьютерных игр до блужданий в компьютерных сетях или личных разговоров по телефону. Следует осуществлять контроль передаваемой информации по компьютерным сетям. Даже если возможности такого контроля нет, можно создать его видимость. Эффект может оказаться неожиданным и крайне позитивным для проекта.
Рассмотренный нами список резервов не является полным. Каждая организация имеет свои секреты и приемы работы, которые могли бы его дополнить. Некоторые из них, возможно, не дадут эффекта. Однако время "шальных" денег прошло, и надо использовать любую возможность их экономии, не забывая при этом, что цель - реализация проекта, а не экономия средств.
Развитие теории управления как науки в России идет по пути адаптации западных технологий управления к нашей действительности. Однако нередко анализ показывает, как правило, если не негативное влияние западных школ, то отсутствие положительного эффекта. Данная глава предлагает к рассмотрению одну из российских технологий поиска решений - "Теории решения изобретательских задач" (ТРИЗ), разработанную Генрихом Альтшуллером и группой единомышленников, которая была очень популярна до перестройки и успешно применялась для решения технических задач. Универсальность основного алгоритма поиска решений позволяет использовать ТРИЗ и в гуманитарных науках. Основной особенностью данного подхода является принципиальная возможность решения нестандартных задач, чего не позволяют сделать западные методики. Рассмотрим возможность применения ТРИЗ в проектном управлении.
В основе теории лежит алгоритм решения задач (АРИЗ), который представляет собой последовательность необходимых действий в процессе поиска решения. При выполнении каждого этапа необходимо тщательно обдумывать его результаты и обязательно записывать все соображения, возникающие по ходу выполнения задачи. Алгоритм содержит девять этапов. Однако нужный ответ может появиться на любом из них. При этом рекомендуется продолжить выполнение алгоритма, так как возможно получение нового решения, превосходящего по результатам уже имеющееся.
Рассмотрим составляющие АРИЗ и попытаемся найти решения для некоторых задач, которые приходится решать менеджерам проектов в коммерческом банке. Описанный ниже алгоритм содержит некоторые отличии от алгоритма, разработанного Альтшуллером, так как был адаптирован авторами под задачи проектного управления.
Итак, первый этап - это анализ. Основная цель первого этапа - переход от расплывчатой ситуации к четко построенной и предельно простой схеме задачи. Этап содержит семь действий, позволяющих четко сформулировать задачу и выявить основные противоречия.
1. Записать условия мини-задачи (без специальных терминов) по следующей форме.
Участники процесса. Указать цели и задачи каждого участника, его возможности и связи. Указать особенности каждого участника и (в случае, если участник - организация или любая другая группа людей) его составляющие.
Противоречия. Перечисляются все противоречия.
Что необходимо при минимальных изменениях. Указать результат, который должен быть получен. Мини-задачу получают из общей проблемы, вводя ограничения: все остается без изменения или упрощается, но при этом задача достигает своего решения или исчезает противоречие. Переход к мини-задаче не означает, что начато решение основной задачи. Наоборот, введение дополнительных ограничений (результат должен быть получен из ничего) ориентирован на обострение конфликта и заранее отрезает пути к компромиссным решениям.
Пример мини-задачи.
Участники процесса:
сотрудник "А". Хороший специалист, знает учет, пользуется уважением в коллективе;
сотрудник "В". Имеет связи за пределами организации. Однако груб с коллегами, имеет ряд недостатков.
Противоречие: между ними имеется скрытое соперничество, выдвижение одного может привести к увольнению другого. В случае увольнения сотрудник "А" может увести с собой и других сотрудников отдела, что существенно нарушит деятельность организации. В случае увольнения сотрудника "В" будет потерян важный клиент.
Необходимо при минимальных изменениях: назначить нового руководителя отдела, удержав обоих сотрудников в организации.
Термины и понятия в описании задачи следует заменять простыми словами без дипломатических уверток. Например, фразу "имеет связи" лучше поменять на описание этих связей: "супруг является директором данной фирмы"; "привел этого клиента в банк (имя); знакомство (учились в одном классе с начальником отдела маркетинга)". Согласитесь, что описание влияния сотрудника "В" в фирме клиента существенно расширяется.
В нашем случае конфликтующей парой являются сотрудники "А" и "В". Данный этап требует дополнительно проанализировать данных сотрудников, учитывая следующие параметры:
* развитие ситуации во времени. В рассматриваемом случае необходимо оценить дальнейший карьерный рост каждого из них, а также их ожидания в продвижении по карьерной лестнице. Например, если очевидно, что один из сотрудников долго на предлагаемой должности не задержится, это может существенно повлиять на принятие вашего решения;
* силу связи участников конфликта с окружающей средой. Здесь надо еще раз оценить, насколько сильно участник конфликта может оказывать влияние на окружающих;
устойчивость участников конфликта к психологическому воздействию. Данный пункт отсутствует в АРИЗ, поскольку технологические процессы не поддаются психологическому воздействию, однако в гуманитарной области это воздействие часто оказывается решающим.
3. Построение графической схемы конфликта.
Очень многие технологии, связанные с поиском решений, рекомендуют графическое отображение процессов. Это объясняется повышенной восприимчивостью человеческого мозга к графическим образам. АРИЗ также предполагает построение подобных графических схем. Какого-то единого стандарта, как, например, в IDEFO, здесь нет. Единственное условие - простота и понятность.
Шаги 2 и 3 уточняют общую формулировку задачи. Поэтому после третьего шага необходимо вернуться к первому, проверить несоответствия и скорректировать их.
4. Выбор типового решения, которое обеспечивает наилучшее осуществление главного процесса.
Этот шаг не приводит к полному решению задачи, однако заставляет провести оценку конфликта и его последствий. Насколько на самом деле увольнение одного из рассматриваемых сотрудников критично для организации? На какие затраты может пойти организация для разрешения данного конфликта? В дальнейшем оценка ущерба от конфликта станет одним из основных параметров поиска решений
5. Построение модели самого плохого развития ситуации. Данный шаг является развитием предыдущего во времени, поскольку значение разовых потерь может быть существенно меньше, чем ущерб, который получит организация впоследствии. Например, в нашем случае это могут быть неуверенность и чувство несправедливости у оставшихся сотрудников, что может привести их к поиску нового места работы.
6. Окончательная формулировка задачи.
Все вышеперечисленные шаги позволяют провести окончательную формулировку задачи, которая должна содержать в себе помимо описания мини-задачи следующие составляющие:
- участников конфликта;
- оценку ущерба, равную наихудшему развитию ситуации при выборе лучшего стандартного решения;
- требования к Х-элементу (под Х-элементом подразумевается изменение в системе, направленное на достижение поставленной цели).
В нашем случае задача будет примерно такой: сохранить профессиональный коллектив отдела, повысив реального лидера коллектива, и при этом не потерять клиента, представитель которого претендует на должность руководителя.
1. Проверить возможность применения стандартных решений подобных задач из разных областей жизни.
В стандартном описании "алгоритма решения задач" систематизация стандартных решений является достаточно большой областью теории, выходящей за рамки данной главы. Для простоты мы воспользуемся простым перебором возможных решений проблемы, когда два объекта стремятся занять одну область. Вот возможные решения.
Разнесение во времени. Сначала вакансия отдается одному сотруднику, затем он переводится на другую должность, и место отдается второму сотруднику.
Разделение области на подобласти. Под данным решением подразумевается разделение основных атрибутов вакансии руководителя на два списка и распределение их между участниками конфликта. Например, сотрудник "А" получает реальную власть в принятии решений, распределении работ, ответственность за результат. Сотрудник "В" получает звание и администраторские функции. Реально этого можно достичь, выделив сотрудника "А" в отдельный проект, контролируемый высшим руководством организации.
Дублирование области. Это часто применяемое решение, заключающееся в создании должности специально под сотрудника с целью удовлетворения его амбиций.
Не решать задачу. Поскольку негативные последствия в рассматриваемом конфликте начинаются только после принятия решения, то одним из решений может стать его отсутствие, что, возможно, приведет к отсутствию конфликта. Учитывая динамичность области задачи, можно ожидать изменения рассматриваемой системы и исчезновения конфликта решений.
Удаление лишнего звена системы, приводящего к конфликту. Если еще раз внимательно перечитать условия задачи, то становится видно, что организации не интересен сам сотрудник "В". Условия требуют сохранения клиента. Сотрудник является всего лишь связующим звеном. Возможно, следует пересмотреть условия задачи и рассмотреть новую задачу по созданию новой связи между организацией и клиентом без посреднических услуг сотрудника.
Помимо этих чисто технических решений для задач управления возможны и психологические решения. Среди них:
подмена цели. Данное решение включает в себя попытку убедить одного из сотрудников, что его настоящая цель заключается не в занимаемой должности, а, например, в финансовом благополучии. В результате, правда, придется повысить одному из них заработную плату;
отвлечение внимания. Увлечь сотрудника решением новой задачи или новым проектом, что сделает потерю должности не столь болезненной и не приведет к критической точке конфликта.
Нет сомнений, что существуют и другие решения рассматриваемой проблемы. Но, так или иначе, задача подобной сложности скорее всего будет решена именно на первом этапе, основной идеей которого является необходимость как следует разобраться в проблеме. Возможно, решение появится само собой. При рассмотрении следующих этапов мы усложним пример и рассмотрим, к каким неожиданным и красивым решениям может привести использование данного алгоритма.
Второй этап - анализ ресурсов. "Цель второго этапа - учет имеющихся ресурсов, которые можно использовать при решении задачи".
Второй этап состоит из трех шагов: определения оперативной зоны, определения оперативного времени и определения финансово-производственных ресурсов. В качестве примера для анализа будет рассматриваться проблема ликвидности активов: "Организации срочно требуются свободные средства для осуществления текущих платежей по договору, однако имеющиеся у нее активы являются низколиквидными. Необходимо найти решение преобразования данных активов в свободные средства с минимальными потерями в определенные сроки".
1. Определение оперативной зоны. В простейшем случае оперативная зона - это область, в пределах которой возникает конфликт, указанный в модели задачи, ограниченная правовыми и этическими рамками. Границами этой зоны является свод обязательных правил, нарушение которых недопустимо при решении задач и. Наиболее часто используются следующие ограничения:
- соответствие законодательной базе - при описании данных ограничений следует четко определить области действия законов. Необходимо контролировать пересечение областей действия задачи и действия различных законов;
- соответствие нормам поведения в обществе и внутренним регламентам.
2. Определение оперативного времени. Оперативное время - это имеющиеся ресурсы времени: время до конфликта и время продолжительности конфликта.
В рассматриваемом примере время до конфликта - это время на подготовку операции перевода активов в свободные средства, время продолжительности конфликта - это время, требуемое на саму операцию. Соответственно сумма обоих временных интервалов должна быть меньше времени до начала платежа.
3. Определение оперативных ресурсов (инструментов). Ресурсы - это средства, доступные в оперативное время в оперативной области для решения задачи. Применительно к задачам управления определяются следующие типы ресурсов:
* ресурсы времени;
* финансовые ресурсы;
* производственные ресурсы;
* людские ресурсы.
При этом следует помнить, что нехватка одного вида ресурсов при решении задачи может компенсироваться избытком другого ресурса, хотя и не всегда. Например, нехватка людских ресурсов может быть компенсирована автоматизацией процесса, то есть производственным ресурсом.
По отношению к области задачи ресурсы также делятся на 3 вида:
1) внутрисистемные - к данному типу относятся ресурсы участников конфликта и внутренние инструменты. Например, находящиеся в активах здания можно сдавать, что даст дополнительные средства. Также возможно в случае, если активы находятся в залоге у организации, попытаться ускорить процесс возврата выданного под данный ресурс кредита;
2) внешнесистемные - к данному виду относятся ресурсы внешней среды, как специфичные для данной задачи, так и общего плана. В рассматриваемом примере это могут быть различные варианты межбанковского кредитования, торговые операции;
3) надсистемные - обычно под данным видом рассматриваются "отходы" посторонней системы или недорогие ресурсы (очень дешевые посторонние элементы, стоимостью которых можно пренебречь). Часто в российской практике к подобным ресурсам относят внеурочное время работы сотрудников, которое не всегда оплачивается дополнительно.
На данном шаге рассматриваются только имеющиеся ресурсы. Их выгодно использовать в первую очередь. Если их окажется недостаточно, в дальнейшем можно расширить поиск. Анализ ресурсов на данном этапе является предварительным.
Определение идеального решения
Третий этап - определение идеального решения. В результате применения третьего этапа АРИЗ должен быть сформулирован образ идеального решения (ИР). Определяются также физические противоречия, мешающие достижению ИР. Не всегда возможно достичь идеального решения, но ИР указывает направление на наиболее сильный ответ.
Для описания идеального решения выполняются следующие шаги.
Записать первую формулировку идеального решения исходя из следующих условий: данное решение, не усложняя существующую систему и не вызывая вредных последствий в течение оперативного времени в оперативной области, должна устранять существующий конфликт, сохраняя основной процесс задачи.
Применительно к рассматриваемой выше задаче первичная формулировка идеального решения может звучать так: данное решение осуществляет своевременную оплату необходимых средств, при этом объем имеющихся активов уменьшается не больше чем на сумму платежа, без каких-либо последствий.
Следует учитывать, что данное описание носит первичный характер, так как очень трудно оценить последствия любого решения, связанные с усложнением системы или воздействием на внешнюю среду.
Усилить формулировку идеального решения дополнительным требованиям использования только оперативных ресурсов. Ограниченность набора оперативных ресурсов позволяет произвести оценку эффективности использования всех их видов и типов, при этом вырабатываются различные возможные линии решений, сформированных путем использования разных типов инструментов и свойств участников задачи. Оценить, какая из линий максимально близко подходит к идеальному решению. При прохождении АРИЗ последовательный анализ постепенно заменяется параллельным. Решение задачи сопровождается ломкой старых представлений. При работе с АРИЗ записи необходимо вести, всячески избегая спецтерминов, поскольку они усиливают психологическую инерцию.
Записать формулировку физического противоречия на макроуровне. Физическим противоречием называют противоположные требования к состоянию оперативной зоны. Например, требование выполнения работы в срок и качественно. При достаточно малом сроке работа не может быть выполнена качественно. В примере с ликвидностью активов противоречие может звучать так: невозможно осуществить беззатратное преобразование одних видов активов в другие. При этом размер затрат определяется оперативным временем задачи. Чем меньше время, тем больше потери.
Рекомендуется также графическое отображение противоречия с отображением воздействия на задачу различных видов решения (рис. 23).
"Рис. 23. Графическое отображение противоречий и возможных решений"
Записать формулировку конечного варианта идеального решения. Три первые этапа АРИЗ существенно перестраивают исходную задачу. Итогом этого процесса являются окончательная формулировка идеального решения и физическое описание задачи. Именно понимание того, что физически невозможно в рассматриваемой проблеме, и делает задачу готовой к окончательному решению по методологии ТРИЗ. Получив физическое описание проблемы, необходимо еще раз просмотреть систему стандартных решений для данной физической задачи. И если она не решена, то переходить к следующему этапу.
Четвертый этап - мобилизация новых ресурсов с целью расширить ресурсную базу, доступную для решения задачи. Данный этап заключается в переборе различных приемов, направленных на увеличение доступных ресурсов и методов их применения для решения задачи. Для поиска новых ресурсов в качестве примера будет использоваться рассматриваемая выше задача нелеквидности активов.
1. Объектное разделение задачи является первым шагом расширения ресурсной базы. При этом определяются инструменты, способные оказывать воздействие на каждый объект задачи, и методы собственно объектов. На данном этапе также рекомендуется применять графические изображения задачи.
В примере мы определим объекты, их методы и методы воздействия на них.
Здание (неликвидный актив) - продажа, залог, сдача в аренду, получение страховки, передача в качестве доли в сторонних проектах, использование для развития собственного бизнеса.
Свободные средства - заем, прибыль, отсрочка других платежей или различные варианты экономии, выпуск векселей.
Платеж - перенос срока платежа, изменение суммы платежа, изменение формы платежа (замена денежной суммы на право владения тем же зданием или на акции самого банка, или на векселя организации).
Возможно, существуют еще множество различных методов рассматриваемых выше объектов, но для примера достаточно и этих.
Из приведенных списков начинают проглядываться принципиально новые доступные решения (передача части имущественного права в качестве платежа или предложения по участию получателя платежа в новом проекте). Возможно, подавляющее число подобных решений более удалены от идеального решения, чем типовые решения, однако среди них возможно присутствие инструмента, позволяющего улучшить показатели уже лучшего из имеющихся решений.
2. Рассмотрение возможности решения задачи смешением различных ресурсов. На данном этапе рассматривается возможность одновременного использования доступных ресурсов. Строятся различные модели решения и рассматриваются влияния каждого из ресурсов на изменения параметров линии решения. В примере отсрочка других платежей и экономия средств могут снизить требуемые денежные ресурсы до такой степени, что появится возможность получения дешевого кредита под залог целого здания без дополнительных экспертиз.
3. Рассмотрение возможности решения задачи ресурсами, являющимися производными от имеющихся. Для того чтобы получить производные ресурсы и методы, необходимо изменить статус имеющихся объектов. Следует попытаться описать имеющиеся объекты другими словами и оценить доступные методы новых понятий.
4. Рассмотрение возможности решения задачи с использованием психологических методов. На данном этапе рассматривается возможность изменения требования к условиям задачи со стороны других людей путем психологического воздействия на них. Даже если получателю платежа не нужны векселя, есть смысл попытаться убедить его в возможности данного решения. Использование психологических методов может оказаться очень эффективным на первом этапе. Однако часто данные методы имеют негативные последствия, поэтому требуется дополнительный анализ их нейтрализации.
Применение информационного фонда
Во многих случаях четвертый этап АРИЗ приводит к решению задачи, однако если ответа до сих пор нет, надо пройти пятый этап, цель которого - использование опыта, сконцентрированного в информационном фонде. К данному этапу задача достаточно проясняется, чтобы эффект от использования информационного фонда был максимальным.
На этом этапе подключаются все возможные источники знаний и типовых решений. К наиболее распространенным источникам относятся:
* знания и опыт окружающих людей;
* литература;
* Интернет;
* специализированные эксперименты;
* консультанты.
При работе с информационным фондом рассматриваются примеры решения похожих задач и опыт использования имеющихся ресурсов. В случае отсутствия какой-либо информации проводятся эксперименты. Кроме того, следует помнить, что каждый человек имеет свой собственный информационный фонд, возможно, включающий в себя недоступные вам источники информации.
Шестой этап - изменение или замена задачи. Простые задачи решаются буквальным преодолением противоречий, например разделением конфликтующих объектов во времени или пространстве. Решение сложных задач обычно связано с изменением смысла задачи - снятием первоначальных ограничений и психологической инерции. Процесс решения на данном этапе в сущности есть процесс корректировки задачи.
Для изменения задачи используются следующие шаги.
Проверить, не является ли формулировка задачи сочетанием нескольких разных задач. Например, как уже стало очевидным, задачу с ликвидностью можно разделить на две: превращение актива в свободные средства и осуществление платежа при отсутствии средств.
Рассмотреть более общую задачу. Для кредитной организации задачей более высокого уровня может быть получение стабильного дохода. Рассмотрение с точки зрения человека, занятого решением этой задачи, других задач может свести их к проблеме, как выкрутиться из создавшейся ситуации с минимальными потерями. Однако не стоит очень углубляться в обобщение задачи, так как в конечном этапе в результате подобных переходов будут достигнуты общечеловеческие ценности, такие, как материальные блага, стабильность, здоровье и т.п., что может увести от решения конкретной проблемы.
На этом этапе АРИЗ заканчивает собственно поиск решения. В случае отсутствия решения шестой этап входит в бесконечный цикл по изменению условия задачи, в каждом из которых приходится повторять 1-6 этапы соответственно.
Последующие этапы связаны с оптимизацией имеющегося решения и его преобразования в универсальное для решения для последующих задач. К этим этапам следует также обращаться в случае, если решение было найдено раньше шестого этапа.
Седьмой этап - проверка полученного ответа, анализ способа устранения противоречия задачи. Главная цель седьмого этапа АРИЗ - проверка качества полученного ответа. Противоречие должно быть устранено почти идеально, с минимальными затратами. Лучше потратить время на получение более сильного решения, чем потом бороться за трудновнедряемую идею.
Анализ решения. Для проведения подобного анализа следует ответить на следующие вопросы:
* Обеспечивает ли полученное решение выполнение главного требования идеального решения?
* Какое противоречие устранено (и устранено ли) полученным решением?
* Управляема ли полученная система?
* Будет ли данное решение работать многократно?
Построение плана внедрения найденного решения. Результатом данного шага должен стать бизнес-план реализации предложенного решения с оценкой затрат на его реализацию. При этом необходимо провести сравнение положительного эффекта и затрат на реализацию и поддержку данного решения. В случае, если решение не применялось ранее и не может быть применено в будущем, рекомендуется как минимум двукратное превышение ожидаемой выгоды над затратами. Если затраты на реализацию слишком высоки, рекомендуется продолжить оптимизацию решения путем анализа эффективности использования дополнительных методов и ресурсов.
Переносимость найденного решения на другие задачи
Восьмой этап - переносимость найденного решения на другие задачи. Действительно хорошая идея не только решает конкретную задачу, но и дает универсальный ключ ко многим другим аналогичным задачам. Цель этапа - максимальное использование ресурсов найденной идеи.
Обычно менеджеру приходится решать однотипные задачи, поэтому любое решение, реализованное успешно, может применяться многократно. В общем случае этот этап не нужен для решения задачи, однако его прохождение может дать большой дополнительный эффект. Однако, если работа ведется не только ради решения конкретной задачи, выполнение этого этапа может стать началом разработки новой концепции управления. Этап включает в себя следующие шаги.
1. Определение изменения в системе более высокого уровня. Необходимо еще раз сформулировать основную идею и рассмотреть, как она повлияла на различные внешние системы.
2. Проверить, сможет ли решенная задача применяться в других ситуациях. Например, если вы в первом примере про двух сотрудников нашли метод, как устанавливать добрые отношения с клиентом, минуя их представителей в вашей организации, разве этот метод недостоин быть примененным ко всем клиентам или использован для привлечение новых? И наоборот, если вам удалось сохранить коллектив, избегнув продвижения в карьере, разве вы не будете использовать этот прием снова и снова?
3. Попытайтесь менять условия задачи, сохраняя общий принцип ее решения. Увеличивайте значения параметров задачи до бесконечности и уменьшайте до нуля, определите диапазон, в котором данный принцип работает, и область наибольшего эффекта. Данный принцип становится особенно понятен в примере с ликвидностью. Уменьшая сумму платежа, вы придете к сумме, которую вы сможете оплатить из своего кармана и, следовательно, ограничить область применения задачи снизу.
4. Рассмотрите возможность использования принципа обратного полученному. Если вы нашли метод, как удержать сотрудника, может быть, где-то рядом находится метод, как от него избавиться.
Девятый этап - анализ хода решения. Как уже говорилось, сама по себе рассматриваемая методика носит общий характер. Она позволяет лишь систематизировать поиск правильного решения. Если вы допустили отклонение от него, постарайтесь проанализировать его причины. И если изменения оказали явно положительный результат, необходимо зарегистрировать их. Однако надо учитывать, что изменения алгоритма, оказавшие положительный эффект при решении одной задачи, могут затруднить решение другой задачи.