Ноябрь 1992 года, Южно-Казахстанское Областное управление Туран банк (бывший ПромСтройБанк СССР). Я только устроился начальником отдела автоматизации. Первое что бросилось в глаза – постоянный конфликт между операционным отделом и отделом автоматизации по поводу открытия счетов.

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

Конфликт состоял в следующем. Операционный отдел все время жаловался что ему или не открыли нужные счета и поэтому не сформировались проводки или открыли не правильно. Отдел автоматизации говорил, что открыли, так как их и просили или что им не давали информации на открытие счета. Все время искали виноватого. Поскольку за операционный отдел вступалась Главный Бухгалтер, то виноватыми, как правило, делали отдел автоматизации.

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

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

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

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

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

Лето 1980 года. Тургайская область (север Казахстана). Студенческий строительный отряд.

Первая задача – выкопать фундамент для двухквартирного дома.

Человек 10 студентов полных энтузиазма заработать денег. Из инструментов ломы и лопаты не новые, и как принято было в те времена с занозистыми черенками плохо закрепленными на штык. Середина лета и верхние 50-70 см почвы – глина усохшая до твердости бетона . Бригадир (студент служивший до института в стройбате. Разделил весь периметр на участки. Объяснил, что в ширину надо копать на 80 см и в глубину на 1.5 метра. Бригада с энтузиазмом бросилась долбить землю ломами и выгребать надолбленное лопатами где-то в 9:00.

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

Жора поняв, что убедить не удастся, решил как минимум свой труд сделать правильным. Нашел где-то ведро, натаскал воды и залил на свой участок. На замечания бригадира: почему делом не занят, ответил, мол закончу не позже других а может и раньше, а работать без подготовки только себя мучить. Черенок зашкурил чтобы не было заноз и шероховатостей которые могли бы натереть руки. Укрепил штык на черенке чтобы он не болтался. Заточил штык напильником чуть ли не до остроты ножа. Начал копать уже часам к 11-ти.

Народ к этому времени успел уже углубиться сантиметров на 30-40 и натереть мозоли, еще больше разболтать штык лопат на черенке.

Копал Жора без лома, так как земля размягчилась от воды, что он полил до начала работ. Острый штык легко входил в землю и Жора к обеду догнал остальных. Часам к пяти он закончил свой участок. Причем стенки были ровными как по линейке. И край точно по разметке. Остальным надо было еще копать процентов 20-30. Земля снизу была помягче, но усталость и мозоли не давали возможности работать быстро. Жора спокойно перекурил на краю своего участка и потом нашел того кто отстал больше всех и стал ему помогать. Закончил народ копать уже в сумерках. Вымотанный, голодный и усталый. Свежим и довольным был только Жора, сделавший по сути дела двойную норму.

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

Выводы:

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

Мои наблюдения из 90-х годов, то как относятся к клиентам на разных СТО и какое отношение в конце концов лучше для клиента.

Можно выделить два подхода отношения к клинету:

1. Шымкентский. СТОшник свой братан. Он всегда тебе рад, много не берет. Готов сделать скидки. Обещает сделать очень быстро. Может бросить текущую работу и заняться твоей машиной. Готов работать с любыми запчастями которые ты принесешь. Если надо, то встанет среди ночи и поедет к тебе на вызов, если ты где-то остановился. Но сделанный им ремонт к сожалению недолговечен, и ты снова и снова приезжаешь к нему. По небольшим суммам в результате тратишь очень много, а проблема окончательно не уходит и всегда есть риск что ты сломаешься где-то в дороге. Ты как бы у него на крючке. Но всегда им доволен, так как он никогда не отказывает, но живешь вечно с проблемой.
2. Немецкий. СТОншник вредный немец. Никогда не бросит текущую работу, чтобы заняться твоей машиной. Но и от твоей машины не будет отвлекаться на другие, если работы начал. Выговорит тебе за грязный двигатель и за то что вовремя не меняешь масло. Не будет называть версий поломки пока досконально не разберется. Никогда не станет ставить на машину плохие детали. Как правило, может сказать, где взять хорошие или как понять что деталь хорошая. Работу не делает впопыхах, на ходу. Не поддается на уговоры сделать поскорее – в порядке очереди и за такое время, какое положено. Но сделанный им ремонт долговечен. Ты просто забываешь о проблеме, может и о самом мастере. Вспомнишь тогда, когда столкнешься с другим стилем обслуживания.

Кто из них по настоящему клиентоориентирован? Что надо на выходе клиенту? Внимательное обращение или качественный ремонт? Постоянное душевное общение с СТОшником и траты с этим связанные, или надежно бегающая машина?

1. ПРОЦЕССЫ ДОПОЛНЯЮЩИЕ ДРУГ ДРУГА.
Процессы управления инцидентами и проблемами настолько взаимосвязаны, что достаточно сильно влияют друг на друга. И могут быть эффективны, только в том случае, если взаимно проникают и дополняют друг друга. Процесс управления инцидентами готовит для процесса по проблемам материал и предварительный анализ, процесс по проблемам устраняет корневые причины проблем. Оба они улучшают сервис. Эффективно это работает и при слаженной работе всех трех уровней сопровождения.

2. ИНЦИДЕНТЫ – ИНДИКАТОРЫ ПРОБЛЕМ.
Любой инцидент произошедший в системе – показатель того, что у кого-то что-то работает не правильно. А значит есть проблемы – технические или организационные. Чем чаще случаются определенные инциденты, тем сильнее влияние этой проблемы на пользователей и клиентов. Чем больше инцидентов разного типа в системе, тем хуже система как сервис. Поэтому очень важно чтобы инциденты регистрировались в системе Сервис Деск. Это поможет нам видеть и проблемные сервисы и проблемные процессы.

3. УСТРАНЕНИЕ ПРОБЛЕМ – ПУТЬ К УЛУЧШЕНИЮ.
Можно отрабатывать по каждому инциденту, устраняя его последствия, пусть даже достаточно быстро. Но тогда будут появляться все новые и новые аналогичные инциденты. Сервис будет таким же проблемным. А если устранить проблему породившую их, то добьемся того, что новых аналогичных инцидентов не будет. Сервис станет лучше.

4. КАКОВ ЭФФЕКТ ОТ СОГЛАСОВАННОГО УПРАВЛЕНИЯ ИНЦИДЕНТАМИ И ПРОБЛЕМАМИ.
Рассмотрим на примере управления инцидентами и проблемами основной банковской системы ИБСО насколько эффективно можно улучшать сервис, когда оба процесса активно взаимодействуют.

4.1. ЛЕГАЛИЗАЦИЯ ПРОБЛЕМ.
Интенсивные работы по улучшению сервиса ИБСО были начаты в первой половине января 2015 года. Надо отметить что внешне ИБСО считался одним из наиболее стабильных сервисов.
Чтобы начать улучшаться, надо выявить и признать все существующие проблемы. К началу работ на ИБСО было зарегистрировано две проблемы, которые считались трудно устранимыми и ими особо не занимались.
Был проведен анализ инцидентов происходящих ежедневно. И было выявлено, что по большей части из них применялись обходные решения, а корневые причины не устранялись. Проблем в системе Сервис Деск не регистрировали и поэтому никто ими не занимался.
Для каждого типа инцидентов были зарегистрированы соответствующие проблемы и проведен по ним анализ.

4.2. ЛЕГАЛИЗАЦИЯ ИНЦИДЕНТОВ.
Поскольку оперативного устранения причин инцидентов не проводилось, то можно было предположить, что по некоторым случаям пользователе уже просто перестали регистрировать инциденты.

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

4.3. ОПРЕДЕЛЕНИЕ ПРИОРИТЕТОВ ПРОБЛЕМ.
Понятно, что в первую очередь надо заниматься разрешением проблем, которые больше всего порождают инцидентов, имеют большее влияние на бизнес или несут большие риски. Из таких желательно выбрать те, которые могут быстро устранены.
Учитывая все эти факторы можно расположить проблемы в порядке устраняя согласно которому можно максимально быстро снижать количество инцидентов и их влияние на бизнес.
После того как такая работа была проведена на ИБСО были определены плановые сроки их устранения согласованные с разработчиками.

4.4. ПЛАНОВОЕ УСТРАНЕНИЕ ПРОБЛЕМ.
Далее была начата работа по плановому устранению проблем в ИБСО. За сроками исполнения и качеством устранения проблем следят менеджер сервиса и владелец системы. Новые выявленные проблемы так же добавляются в общий реестр подвергаются анализу, выявлению корневой причины, определение путей устранения, получают приоритет и планирования сроков устранения. И далее устраняются в плановом порядке.
В результате легализации проблем в список было добавлено 15 новых проблем. В результате планового их устранения количество инцидентов за первый квартал уменьшилось в более чем три раза

4.5. ДИНАМИКА РЕГИСТРИРУЕМЫХ ИНЦИДЕНТОВ РЕГИСТРИРУЕМЫХ ПО СЕРВИСУ ИБСО ЗА 1 КВАРТАЛ 2015 ГОДА.
В течении января месяца по сервису проводилось выявление всех проблем и инцидентов. Этим обусловлен некоторый рост инцидентов в этом месяце.
В течении февраля месяца были устранены наиболее критичные проблемы, что привело к уменьшению инцидентов на 50% (в два раза). В марте были устранены уже менее критичные проблемы, что привело к уменьшению инцидентов еще на 20% от первоначального. В целом за два месяца количество инцидентов уменьшилось на 70%, т.е. более чем у три раза.
Приведенный пример наглядно показывает, что если управление инцидентами и проблемами работают как одно целое, то эффект может быть получен быстрый и эффективный.
Понятно, что такое резкое снижение может быть только в начале. Далее это будет не так резко, поскольку останутся проблемы которые достаточно редко порождают инциденты и решение их не такое простое.
В январе 2016 года в ИБСО было зарегистрировано 79 инцидентов.

1. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В КАЗАХСТАНСКИХ БАНКАХ
Традиционно в казахстанских банка доработка банковского ПО велась «на коленке». Классическая «водопадная» схема бизнес как правило не устраивает, поскольку предполагает, что 90% требований к разрабатываемому (дорабатываемому) модулю должны быть продуманы и зафиксированы, а это большой труд требующий предвидения и тщательного бизнес анализа. Поэтому проще было начать что-то, а потом долго переделывать, пока не получится что-то похожее на то что ожидалось. Понятно что при этом почти не возможно гарантировать каких-то сроков завершения доработок. Они спонтанно могут продолжаться неопределенное время. Понятно что и качество доработок при это сильно страдает, поскольку требования на ходу меняются, тестов тщательных не проводится, а когда уже сроки все истекли стараются сдать то что получилось.
Если в 90-х годах банкам надо было обеспечить хоть какую-то доработку имеющегося банковского ПО, то в к 2010-м годам надо было обеспечивать еще и достаточно хорошую динамику разработок. При этом мы понимаем, что банковское программное обеспечение должно быть к тому же еще и очень надежным. Поскольку финансы не любят неоднозначностей, а лояльность клиентов зависит от того насколько качественно и бесперебойно их обслуживают. И планируемые банковские продукты должны выходить в оговоренные сроки. Т.е . Банковская разработка должна обеспечивать надежность, качество, гибкость и обеспечение запланированных сроков

2. КАК СОВМЕСТИТЬ В РАЗРАБОТКЕ БАНКОВСКОГО ПО ГИБКОСТЬ И НАДЕЖНОСТЬ.
В 90-х годах начинает развиваться и становится популярной в западных станах технология предложенная компанией Rational Software, позволяющая обеспечить и гибкость и качество в разработке критичного программного обеспечения - Rational Unified Process (RUP) - унифицированный процесс разработки. Процесс в общем то является прародителем столь популярных ныне гибких методологий разработки. С той разницей, что у него можно было найти описание множества артефактов, а в гибких методологиях предполагается, что эти артефакты породят команды.
Идея подхода Rational Unified Process такая: по разрабатываемому модулю пишется Концепция (видение основных моментов и высокоуровневых требований) . Потом разработка делится на небольшие итерации в одну две недели. Первыми в работу берутся те участки на которых уже более детальные требования известны, и которые лежат в основе продукта и могут уже как-то работать. Требования по остальным итерациям постепенно уточняются. Т.е. все требования к началу разработки не детализируются, и могут меняться до тех пор пока итерация с этими требованиями не взята в работу.

3. RUP В РАЗРАБОТКЕ БАНКОВСКОГО ПО
RUP 2009 году был принят как основа для разработки процесса управления изменениями в kaspi bank. Понятно что RUP нигде не внедряется полностью как описан. Он адаптируется под каждый конкретный случай. Берется только то, что может быть полезным.
По RUP процесс разработки состоит из трех этапов: анализ, разработка, тестирование (как отдельный этап можно считать внедрение). Разработчики были разбиты на соответствующие тройки: аналитик, разработчик, тестер. Каждая тройка работает на определенное бизнес направление у которого есть свой бизнес заказчик. Разработка оформляется запросом на разработку. Весь объем разработки по запросу делится на итерации (заявки) по 6-9 рабочих дней на три этапа. Запросы выстраиваются в очередь. Приоритеты в очереди запросов может поменять бизнес заказчик этого направления самостоятельно, пока запрос не взят в работу. По взятому в работу запросу приоритеты не меняются. И требования тоже.
По запросам система автоматически считает плановые сроки завершения исходя из того на сколько итераций они разбиты. При смене приоритетов плановые сроки автоматически пересчитываются. В каждый запрос вкладываются высокоуровневые требования. Детальные требования прорабатываются уже в пределах итерации когда она взята в работу. Итерации переходят от одного участника разработки к другому поэтапно и в каждый момент времени каждый из них занят очередной работой. Скажем если запрос состоит из трех итераций (заявок), то в момент когда тестер работает с первой итерацией, разработчик работает со второй, а аналитик с третьей. Причем каждая итерация как правило содержит законченный функционал который можно уже переносить на рабочую схему. В крайнем случае собираются несколько итераций которые можно перенести на рабочую схему как работающий функционал.
Для сбора, анализа и фиксации требований были разработаны опросники и спецификации бизнес требований, для модуля (продукта), операции, представления, отчета. Для обеспечения качественного программирования были написаны правила программирования регламентирующие как оформлять код, как обыгрывать какие ситуации. Для обеспечения выполнения правил программирования были разработаны правила тестирования ПО на соответствие бизнес требованиям и требованиям надежности. Был организован выборочный контроль каждого этапа разработки с заполнением чек листов.
Разработка ведется на отдельных серверах, тестирование - на отдельных. Перенос на рабочую схему проводят специально выделенные люди, не разработчики и не тестеры, а работники сопровождения.
Автоматизация процесса управления изменениями ПО была реализована на продукте компании Rational Software – Clear Quest – специализированный продут по управлению изменениями. Но базовый функционал был существенно доработан чтобы обеспечить управление очередями, управление требованиями, управление ошибками и дефектами, автоматический контроль по пересечению разработок и управлению версиями, интеграция с банковской системой и 1С.
В системе работают как работники ИТ, так и бизнес заказчики. Разработана отчетность по показателям как процесса в общем, так и по каждому направлению и работнику. На основе информации из системы построена система мотивации участников разработки по тому насколько вовремя и качественно выполняются разработки. Рядовым работникам до 25% от базовый ЗП выплачивается в виде премиальных бонусов.

4. ЧЕГО УДАЛОСЬ ДОСТИГНУТЬ ИСПОЛЬЗУЯ RUP В РАЗРАБОТКЕ БАНКОВСКОГО ПО?
Внешне кажется что процесс разработки должен был бы удлинится, так как в нем появилось много новых обязательных работ и этапов.
Посмотрим как изменились показатели процесса управления изменениями на примере департамента банковских систем, который ведет доработку основной банковской системы ИБСО производства центра финансовых технологий за период 2011 – 2014 годы. При этом надо отметить, что количество разработчиков оставалось неизменным
•Соответствие плановым срокам возросло в 2.9 раза
•Время реализации заявки (6-9 нормодней) уменьшилось в 5.7 раза
•Заявок закрывается в 3.2 раза больше
•Нормодней выполняется в 2.2 раза

На рисунках 4.1. - 4.4. представлена динамика по метрикам процесса

5. ЗА СЧЕТ ЧЕГО УДАЛОСЬ ДОСТИЧЬ ТАКИХ РЕЗУЛЬТАТОВ?
Наглядно что изменилось в процессе можно увидеть на диаграммах показывающих как время жизни заявки средне статистически распределялось по этапам процесса. Причем в процессе фиксируются как сами этапы анализа, разработки, тестирования и внедрения, так и промежуточные периоды ожидания начала этапов.
На диаграмме 2012 года видно, что этапы ожидания разработки после анализа и ожидания тестирования после разработки занимают почти 50% всего времени жизни заявки (итерации).
А на диаграмме 2014 года эти два не производительных этапа занимают всего 11%. А 50% занимает этап ожидания анализа. Это этап нахождения запроса в очереди и это вполне нормальный показатель.