СОЗДАНИЕ ЛИЧНОГО КАБИНЕТАВ ЭЛЕКТРОННОМ

ПРАВИТЕЛЬСТВЕ РЕСПУБЛИКИ КАЗАХСТАН

Нурмагамбетова МаусымжанBee Software, Astana

НЕМНОГО О СЕБЕУчастие в реализации проекта автоматизации деятельности ЦОН (автоматизации государственных услуг)

Участие в обсуждении проекта закона «О персональных данных»

Участие в разработке «эталонных (справочных) моделей» «электронного правительства» РК и разработке архитектуры eGov/mGov

Разработка и защита концепции системы «e-Learning» для Республики Казахстан и авторское сопровождение проектаВедение проектов развития eGov/mGov в качестве главного аналитика со стороны компании Bee Software

ИСТОРИЯ РАЗВИТИЯ «ЭЛЕКТРОННОГО ПРАВИТЕЛЬСТВА»

РК

СозданиеГБД

Создание ПЭПавтоматизация госуслуг (~200)

Создание иавтоматизация ЦОНов (~700)

Созданиемобильного правительства

Создание Личного кабинета

ПРЕДЫСТОРИЯ

Концепция

АРХИТЕКТУРА EGOV 1.0 (КОНЦЕПТУАЛЬНО)

ИСТОРИЯ РОЖДЕНИЯ ИДЕИ

Принят закон«О персональных

данных»

Была пройдена «критическая точка» перехода количества в иное качество, в смысле

информатизации

В eGov накопился определенный объем проблем, требующих модернизации

С проектом mGov,появлялись новые

каналывзаимодействия

Личный кабинет - это «вишенка на айсберге» инфраструктуры «электронного правительства» РК.

Причем, во многих смыслах.

КЛЮЧЕВЫЕ НАЧАЛЬНЫЕ ПРИНЦИПЫЕдиная точка входа, единый идентификаторВыделение потока информации, касающегося конкретного лица и направление по удобым каналамПредложение услуг, потенциально интересующих конкретное лицо (предвосхищение потребностей)Защита персональных данныхЛегитимизация и переиспользование данных

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

АГЕНТЫ ВЛИЯНИЯ (СТЕЙКХОЛДЕРЫ)

Команда

Партнеры

Службаинформбезопасности

Заказчик Управлениепроектом

от Заказчика

Службатехническо

гообслужива

ния Департаментархитектуры

ВладельцыИС ГО

ПЕРВОНАЧАЛЬНАЯ АРХИТЕКТУРА ЛИЧНОГО КАБИНЕТА

PD

Ntf

SBSCR HIS

SBSCR SBSCR SBSCR SBSCR SBSCR

CA

SMSPUSH

etc...

АРХИТЕКТУРА ЛИЧНОГО КАБИНЕТАЧТО ПОЛУЧИЛОСЬ В ИТОГЕ

PD

Ntf

SBSCR HIS

CA

SMSPUSH

etc...

ШЭП 1.0 ШЭП 2.0

Brd

DOC

КАК СОХРАНЯЛИСЬ ПРИНЦИПЫ

Концепция

Новое требован

ие

Проверка Обсужден

ие

Выработка решений

ПРИНЦИПЫ ПОСТРОЕНИЯ АРХИТЕКТУРЫ

Унификация всех взаимодействий, объектов и представлений

Специализация

Независимость реализации от способа доступа пользователя

Разделение на слои

ПРИНЦИПЫ УПРАВЛЕНИЯ ПРОЕКТОМГлубокая проработка контекста проекта

Обмен «услугами» с партнерами для страхования рисков

«Никогда не приходить к Заказчику с пустыми руками»Поиск взаимовыгодых решений при конфликте интересов

Выработка совместных решений ДО обсуждения с Заказчиком

Любой проект или отдельная задача в проекте - это вопрос достижения локального оптимума. Основной вопрос как его найти и на нем остановиться.

ПРИМЕРЫ РЕАЛИЗАЦИИ ПРИНЦИПОВ1. «Концепции должны рождаться в одной голове, но прорабатываться совместно» - как мы проектировали сильносвязанную часть подсистем с Партнерами2. «Ты мне, я тебе» - страхование взаимных рисков3. «12 подвигов аналитика» - или как получить еще 100 подписей за последнюю неделю проекта

ПРИМЕРЫ РЕАЛИЗАЦИИ ПРИНЦИПОВ

Если вы идете навстречу друг другу, то вы бестрее достигнете цели. Если вы идете в разных направлениях, то почему вы считаете что это один проект?

4. «Слово на вес золота» - как вы можете выиграть еще немного времени, или о доверии5. «Планы - ничто, планирование - все» - как одновременно добежать в 2 точки6. «В поисках смысла» - как выйти из ситуации когда в договоре оказались «кривые формулировки»

НЕКОТОРЫЕ РЕЗУЛЬТАТЫ ПРОЕКТА

Активных пользователей: ~ 50%Общий объем интеграций: 87 ИС

Всего пользователей: ~ 300 000

АРХИТЕКТУРА EGOV 2.0(КОЦЕПТУАЛЬНО)

«Надводная часть айсберга...»

ЧТО НЕ ПОЛУЧИЛОСЬ И ПОЧЕМУИзменить модель работы ГО для реализации части возможностей СистемыУнифицировать в полной мере взаимодействие с внешними системамиПолноценно реализовать изначально предполагаемые задачи

ВЫВОДЫ И РЕКОМЕНДАЦИИЧто может быть полезно:

- Разделение требований и архитектуры на «условно постоянные», «малоизменчивые» и «быстроменяющиеся»

- Понимание интересов всех сторон, отказ от примитивного эгоизма

- Готовность к изменениям, изменения как часть культуры проекта, проактивность

ВЫВОДЫ И РЕКОМЕНДАЦИИ

Единственный способ успеть к финишу вовремя в проектах «FixedPrice/FixedTime» это сместить время старта в прошлое

Что может быть полезно:

- Фиксация договоренностей на коротком этапе

- Жесткое соответствие всем формальным юридическим критериям успешности проекта (включая опечатки, двусмысленые формулировки и проч.) всей командой

- Стандартизация, унификация, разделение, особенно для «электронного правительства»

ПРИМЕР МЕТАТОДЕЛИ УСЛУГИ