2. с мая 2014 года – ТОО «Bee Software»
• Ведущий аналитик проекта «Открытое правительство»
с июля 2013 года – АО «Национальные
информационные технологии»
• Руководитель проекта «Сопровождение «Электронного
правительства»
с августа 2011 года – АО «Национальные
информационные технологии»
• Аналитик проекта «Развитие «Электронного
правительства»
• Аналитик Департамента создания
портала «электронного
правительства»
АРЫСТАМБЕКОВА АЯУЖАН
Аналитик –практик в области анализа и моделирования бизнес -процессов, член СПМ РК,
участница проектов создания и сопровождения ИС для государственного сектора
2
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
Если окинуть взглядом слайд, то сразу бросается в глаза, что почти все проекты, в которых я принимала участие находятся в государственном секторе.
Каждое государство имеет свои особенности и свои предпочтения.
Сегодня мы разберем на конкретной тематике пару интересных проектов, из которых можно взять что-то для себя.
Не все проекты были реализованы гладко, но каждый из них помог мне, в рамках моего профессионального роста.
Перейдем теме:
Здесь приведен краткий обзор проектов, на примерах, которых я буду показывать те или иные методы, которые применялись для реализации проекта, в условиях
постоянных изменений со стороны Заказчика ( В нашем случае Заказчиком выступало государство, которому перечить было сложновато).
Проект «Создание Электронного правительства» Республики Казахстан стартовал в 2007 году.
Все проблемы, мы будем рассматривать на малой единице – 1 государственная услуга.
Сбор требований включает в себя следующие работы:
Беседа с экспертом из ведомства, предоставляющего услугу;
Изучение нормативной документации для оказания государственной услуги в неавтоматизированном формате;
Изучение информации, хранящейся в автоматизированных информационных системах (далее –ИС);
Создание схем «как есть», «как будет»;
Корректировка схем с экспертом из ведомства;
Согласование интеграций с ИС – для получения сведений;
Создание постановки для реализации;
Создание нормативной документации для легитимизации оказания государственной услуги через портал «Электронного правительства»;
Проблемы:
Отсутствие рычага давления:
1) За предоставление услуги отвечало ведомство, в стратег.планах и показателях, которого не было работ по автоматизации услуги;
2) Ведомство, отвечающее за автоматизацию государственных услуг, имело равные права, как и ведомство – предоставитель услуги;
3) Поставщики (компания, в которой я работала на тот момент) – не имели отношения к государственному сектору, следовательно не имело рычага давления на предметников.
Отсутствие легитимных документов:
1) Результат автоматизированной государственной услуги не признавался законным документом;
2) При согласовании легитимных документов были внесены изменения, влекущие изменения в реализованную услугу, но бюджет на изменение не выделен. Так как 2 раза на реализацию одной услуги бюджет выделять затратно.
Проект «Создание Электронного правительства» Республики Казахстан стартовал в 2007 году.
Все проблемы, мы будем рассматривать на малой единице – 1 государственная услуга.
Проблемы:
Отсутствие артефактов беседы со специалистами, которые реализовывали раннее портал, документирование;
Различие технологий, примененных для реализации решений переписание с нуля всех систем, необходимых для консолидации;
Переход с других систем исследование бизнес-процессов, упрощение и оптимизация бизнес- процессов;
Миграция исторических данных поэтапный план;
Отсутствие легитимных документов подключение юристов Заказчика;
Многочисленные интеграции исследование/встречи/разработка
Мы сдавали проект курирующему ГО без участия Минфина и Мин.экономики, т.е. прямых будущих пользователей;
Мы не успели отследить законодательные документы, которые регламентировали – как должен работать новый функционал;
В договоре было четко прописано, что оплата после выполнения полного объема, т.е. мы фактически оказались в руках наших Заказчиков, которые заставили нас изменить функционал трижды, прежде, чем выплатить деньги;
Сколько ресурсов это потребовало:
Количество аналитиков увеличилось вдвое;
Количество разработчиков увеличилось втрое;
Сроки сдачи проекта были передвинуты на 15 дней
Кризис. С первого взгляда, вроде бы это социальная причина, так почему же мы его учитываем? Потому что кризис хоть и косвенно, но влияет на финансирование ИТ-сектора. Особенно это заметно по уменьшению аппетитов в государственном секторе, да и частный сектор, ориентированный на результат, старается уменьшить свои расходы.
Пример, как кризис в 2015 году повлиял на планы одной ИТ-компании. Скажем так, на казахстанском рынке появилась зарубежная ИТ-компания –X, которая заключила договор в начале 2015 года в тенге (договор с фиксированной суммой), выполнила все свои обязательства, и получила выплату, и проиграла. И что тут такого? – скажете Вы. Но тут одна оговорка, одна и та же сумма в начале и конце 2015 года имела разный вес, так как доллар вырос к концу года почти вдвое. И компания вместо основной выплаты и дополнительного бюджета, едва покрыла все свои расходы. (з/п выплачивалось сотрудникам тоже в долларах).