Доклад Аяужан Арыстамбековой на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com

1. Аяужан Арыстамбекова
Смена правил игры:
что делать, когда вы далеки от старта проекта?
1

2.  с мая 2014 года – ТОО «Bee Software»
• Ведущий аналитик проекта «Открытое правительство»
 с июля 2013 года – АО «Национальные
информационные технологии»
• Руководитель проекта «Сопровождение «Электронного
правительства»
 с августа 2011 года – АО «Национальные
информационные технологии»
• Аналитик проекта «Развитие «Электронного
правительства»
• Аналитик Департамента создания
портала «электронного
правительства»
АРЫСТАМБЕКОВА АЯУЖАН
Аналитик –практик в области анализа и моделирования бизнес -процессов, член СПМ РК,
участница проектов создания и сопровождения ИС для государственного сектора
2

3. Реализованные проекты
Сотрудничество
АРМ ЦОН
Платежный шлюз
3

4. О ЧЕМ ПОЙДЕТ РЕЧЬ?
• «Смена правил» что это? Где возникает?
• Типичные ошибки. Очевидные способы решения.
• Что делать, если типичные решения не сработали?
ЧТО НУЖНО ЗНАТЬ ДЛЯ РАБОТЫ С ГОСУДАРСТВОМ?
РАЗБОР ОШИБОК НА КОНКРЕТНЫХ ПРОЕКТАХ.
• Какие «подарки» несут в себе государственные
проекты?
• Как мы их решали?
• Что характерно только для Казахстана?
• Как это применимо в России?
4

5. •Смена правил - внешние изменения
в предопределенные соглашения,
влияющие на процесс реализации
проекта и на результат
«СМЕНА ПРАВИЛ» ЧТО ЭТО?
•Далеко от старта- все стадии
проекта, где этап «Сбор
требований» (RUP, SCRUM) уже
исполнен
ГДЕ ВОЗНИКАЕТ?
5

6. Отсутствие анализа
законодательной основы
Просчет в расчете ресурсов
проекта
Упущение тонкостей
автоматизируемого процесса
Отсутствие анализа данных
взаимодействующих ИС
С чем мы
столкнулись?
Отсутствие границ проекта
Отсутствие критериев успеха
проекта
Предварительное
обследование законодательства
Учет прогнозируемой
масштабируемости
Обследование специфики
предметной области
Анализ данных ИС
Согласование границ проекта
перед инициацией проекта
Согласование критериев
успеха проекта
6
Проблемы Решения

7. 3 РЕАЛЬНЫХ ПРОЕКТА, ГДЕ НЕ СРАБОТАЛИ
ТИПИЧНЫЕ РЕШЕНИЯ:
•Портал «Электронное
правительство»
•Шлюз «Электронное
правительство»
•Открытое правительство
7

8. Проект «Создание Электронного правительства»
Цель:
 Автоматизация процесса получения государственных
услуг для граждан и бизнеса.
РАЗБОР КОНКРЕТНЫХ ПРИМЕРОВ.
Как выглядит процесс реализации государственной услуги?
Сбор требований Разработка Тестирование
Запуск в
пилотную
эксплуатацию
Запуск в
опытную
эксплуатацию
1 2 3 4
Отправка на доработку
Выпуск нового релиза
8

9. Проект «Создание Электронного правительства»
РАЗБОР КОНКРЕТНЫХ ПРИМЕРОВ.
Проблемы Отсутствие легитимных
документов
Отсутствие рычага давления на
другие ОИВ
Высокая цена ошибки
Сложная предметная область
Реформа административного
деления 9

10. Как мы их решали?
разработка функционала, позволяющего произвести
гибкую настройку, при внесении изменений;
предварительное обследование нормативной
документации,
рекомендательных советы Заказчику по внесению тех
или иных изменений в документы (до реализации);
параллельные процессы: реализация и согласование
легитимной документации,
привлечение юристов;
привлечение экспертов по предметной области;
пилотные запуски по выбранным участкам;
РАЗБОР КОНКРЕТНЫХ ПРИМЕРОВ.
10

11. Что мы имеем сейчас?
• Портал «электронного
правительства» сейчас
предоставляет более 200
услуг;
• Процесс сбора и
отработки требований
налажен так, что нет
необходимости в
привлечении больших
ресурсов.
РАЗБОР КОНКРЕТНЫХ ПРИМЕРОВ.
11

12. Проект «Шлюз Электронного правительства»
Цель:
• Обеспечить маршрутизацию всех используемых государственных и
негосударственных сервисов через единую точку доступа.
Гос.сервис
Сведения о
детях
Ком.сервис
Наличие
кредита
ШЭП
ИС 1
ИС 2
ИС 3
ИС -потребители
проксирование
Схема работы ШЭП
12
ИС 1
ИС 2
ИС -поставщики

13. Проект «ШЭП»
Проблемы Недостаток ресурсов
Низкая скорость
передачи данных
Ограничения
количества сервисов
Отсутствие рычага давления на
другие ИС
Отсутствие доступа к
сведениям у некоммер.сектора
Проблемы с
интеграцией
Уязвимости
Ddos-атаки, угрозы
и взломы
Доступ к гос.данным
13
РискиПроблемы

14. Как мы их решали?
предварительный анализ будущих интеграций,
оценка затрат на ресурсы, при реализации интеграций;
 оплата ресурсов за счет интегрируемого ведомства;
 рекомендательных советы Заказчику по внесению тех
или иных изменений в документы (до реализации);
консалтинг ЗЛ интегрируемых систем;
журналирование;
логическое разделение шлюза на внешний (для
негосударственных организаций) и внутренний
(государственные ведомства).
РАЗБОР КОНКРЕТНЫХ ПРИМЕРОВ.
14

15. Проект «Создание Открытого правительства»
Цель:
Основная цель проекта – обеспечение прозрачности деятельности
государственных органов
Компоненты
15
Открытые
бюджеты
Открытые
данные
Открытые
НПА
Открытый
диалог
Открытое
правительство
Примечание:
* «Открытые бюджеты», «Открытые данные», «Открытые НПА», «Открытый диалог» - это компоненты,
которые входят в состав проекта «Открытое правительство»

16. Проект «Открытый диалог»
Цель: Предоставление возможности гражданам вести диалог с
государством в цифровом пространстве;
Как это должно быть реализовано?
Интернет-
конференции
Блоги первых
руководителей
Электронное правительство
Открытый диалог
Открытое правительство
Опросы
16

17. Различие технологий
Переход с других систем
Миграция исторических
данных
Отсутствие легитимных
документов
С чем мы
столкнулись?
Отсутствие артефактов
Многочисленные интеграции
Разработка с нуля
Оптимизация бизнес-
процессов
Планирование
Сотрудничество с
юристами
Специалисты
Предварительное
согласование
17
Проблемы Решения

18. Компонент «Открытые бюджеты»
 Цель: Предоставление возможности гражданам иметь доступ к
мониторингу исполнения бюджета государства;Проблемы
Отсутствие видения у
Заказчика
Смена законодательства
Отказ от сотрудничества
Предметная область –
не исследована
Отсутствие доступа к
истор.сведениямСмена требований на этапе
реализации
Оплата после выполнения
проекта 18

19. Как мы это решали?
изучение документации по предметной области;
внедрение в организационные работы Заказчика;
выявление прямых и косвенных показателей успеха;
создание и продвижение собственного видения
Заказчику;
создание гибкой поддержки изменений.
19

20. Компонент «Открытые бюджеты»
Ошибки, которые мы не смогли предотвратить:
1. не учтены требования конечных пользователей;
2. уязвимость в условиях оплаты в договоре;
3. изменения в законодательстве.
К чему это привело:
1. Пришлось переписать 70% уже согласованной документации;
2. Реализовать в течение 1, 5 месяцев функционал, который нуждался в
более основательной разработке;
3. Учесть кейсы для 2015 года и для 2016 года, так как никто не знал –
будет ли переход на новый формат в январе 2016 года?
4. Средний показатель переработки на проекте -36-42%.
20

21. ФИНАНСОВЫЙ КРИЗИС В ГОСУДАРСТВЕ
 Уменьшение
финансирования для
государственных проектов;
 Риск проигрыша, при расчете
бюджета.
21

22. ПОЛУЧЕННЫЕ УРОКИ:
Оплату за реализацию отдельных компонентов
проекта необходимо прописывать четко в
договоре;
Бюджет на выполнение проекта должен
высчитываться с риском наступления кризиса.
22

23. КАКИЕ РИСКИ МОГУТ ВОЗНИКНУТЬ В РОССИИ?
Все выше разобранные риски могут возникнуть и в России, и в
других государствах СНГ в реализации государственных
проектов.
ЧТО ХАРАКТЕРНО ТОЛЬКО ДЛЯ КАЗАХСТАНА?
Структура государственного управления;
Территориальное деление;
Особенности этапов выделения бюджета (бюджет выделяется в
сентябре).
23

24. Ваши вопросы
Skype: arystambekova_a_t
Электронный адрес: ayauzhan.arystambekova@bee.kz
24