Введение: методологические основания

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

Базовый принцип, из которого мы исходим, сформулирован учеными усуль аль-фикх: «Основа в вещах - дозволенность» (الأصل في الأشياء الإباحة). Этот принцип относится к мирским вещам, обычаям и средствам. Вместе с тем в вопросах поклонения действует другой принцип: основа в видах ибадата - следование откровению, а не произвольное установление.

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

Раздел 1. Понятие тагута и условия корректного применения этого термина

Слово «тагут» (طاغوت) происходит от арабского корня, означающего преступание границ. Ибн аль-Каййим определял тагут как все, в чем раб преступает пределы в поклонении, следовании или подчинении.

Всевышний Аллах сказал:

لا إكراه في الدين قد تبين الرشد من الغي فمن يكفر بالطاغوت ويؤمن بالله فقد استمسك بالعروة الوثقى

«Нет принуждения в религии. Уже ясно отличился прямой путь от заблуждения. Кто не верует в тагут, а верует в Аллаха, тот ухватился за самую надежную рукоять» Сура Аль-Бакара, 2:256

Важно подчеркнуть: в классической суннитской традиции тагутом называют не всякий сложный или влиятельный предмет, а то, что становится объектом поклонения, ложного суда или безусловного подчинения вопреки откровению. В учебных матнах по таухиду и их комментариях упоминаются «главы тагута», однако общий смысл остается одним: тагут связан с приписыванием творению того, что принадлежит только Аллаху.

ИИ - это созданная людьми вычислительная система с различной степенью автономности. Он не является нравственно ответственным субъектом (мукаллафом), не обладает душой и не знает сокровенного. Поэтому называть ИИ тагутом в прямом богословском смысле некорректно. Однако человек может своим отношением к ИИ придать ему место, подобное месту ложного авторитета или ложного ориентира.

Раздел 2. Реальные угрозы вероучению при неправильном использовании ИИ

2.1. Угроза таваккулю (упованию на Аллаха)

Таваккуль (التوكل) - одно из величайших деяний сердца. Он означает упование на Аллаха при использовании дозволенных средств. Всевышний сказал:

ومن يتوكل على الله فهو حسبه

«Кто уповает на Аллаха, тому Его достаточно» Сура Ат-Таляк, 65:3

Ибн аль-Каййим разъяснял, что таваккуль не исключает причины и средства (асбаб), но требует, чтобы сердце полагалось на Аллаха, а не на сами средства.

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

2.2. Угроза в сфере законодательства и морального авторитета (ташри')

В исламской акиде право окончательно устанавливать халяль и харам принадлежит исключительно Аллаху. Всевышний сказал:

إن الحكم إلا لله أمر ألا تعبدوا إلا إياه

«Власть и решение принадлежат только Аллаху. Он повелел, чтобы вы не поклонялись никому, кроме Него» Сура Юсуф, 12:40

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

Второй уровень - случаи, когда ИИ-системы или стоящие за ними институты фактически предлагают человеку завершенную моральную картину мира и требуют признать ее выше или вместо того, что установлено Кораном и Сунной. В этом случае возникает опасность подчинения иному нормативному авторитету вопреки откровению. Аллах сказал:

اتخذوا أحبارهم ورهبانهم أربابا من دون الله

«Они взяли своих книжников и монахов господами помимо Аллаха» Сура Ат-Тауба, 9:31

Пророк ﷺ объяснил Ади ибн Хатиму, что «поклонение» книжникам и монахам состояло не в земных поклонах, а в следовании их дозволениям и запретам вопреки закону Аллаха. По аналогии, если мусульманин без критерия откровения принимает алгоритмически навязанные нравственные установки как безусловную истину, он подвергает веру серьезной опасности. При этом речь идет о виде деяния в общем; решение о конкретном человеке требует наличия условий и отсутствия препятствий и возвращается к ученым. Сам ИИ не является «господином» - ответственность лежит на людях, которые создают, внедряют и абсолютизируют эти системы.

2.3. Угроза гафле (небрежности в поминании Аллаха)

Погружение в цифровые миры - метавселенные, бесконечные ленты контента, генеративные развлечения - может вести к состоянию гафля (غفلة), то есть небрежности в отношении поминания Аллаха. Всевышний предупредил:

ولا تكن من الغافلين

«И не будь из числа небрежных» Сура Аль-Аъраф, 7:205

Это не проблема только ИИ: любое чрезмерное увлечение мирским способно отвлечь сердце. Однако ИИ усиливает эту угрозу за счет непрерывной, персонализированной и эмоционально вовлекающей подачи контента. Дозволенное по исходной основе может стать вредным, если оно занимает сердце, время и внимание настолько, что ослабляет зикр, знания и поклонение. Эту логику подробно описывал аль-Газали, разъясняя, что даже дозволенное может стать преградой, если полностью поглощает человека.

2.4. О ложных обещаниях: трансгуманизм и «цифровое бессмертие»

Некоторые идеологии, связанные с развитием ИИ, продвигают идеи «цифрового бессмертия» - сохранения сознания в цифровой форме, преодоления биологической смерти и замены традиционного представления о человеческой природе.

كل نفس ذائقة الموت

«Каждая душа вкусит смерть» Сура Аль-Имран, 3:185

С точки зрения исламской акиды смерть - установленная Аллахом реальность. Вера в Последний день, включая воскрешение после смерти, - один из шести столпов имана. Убеждение в том, что технология может заменить воскресение, отменить предопределенную смерть или обеспечить вечную жизнь независимо от воли Аллаха, противоречит основам веры. Вместе с тем стремление лечить болезни, продлевать жизнь дозволенными средствами и использовать технологии во благо само по себе не является запретным.

Раздел 3. Шариатские нормы использования ИИ

Исходя из вышеизложенного, можно сформулировать следующие принципы, основанные на общих правилах фикха:

3.1. Принцип исходной дозволенности

ИИ как вычислительный инструмент в основе дозволен. Его использование в медицине, науке, образовании, безопасности, управлении и других полезных сферах относится к мирским средствам. В зависимости от цели такое использование может быть мубах, желательным, а иногда и обязательным - например, когда оно становится необходимым средством сохранения жизни, здоровья, имущества или общественной безопасности.

3.2. Принцип средств (аль-васаиль)

Правило фикха гласит: «Средства получают хукм своих целей» (للوسائل حكم المقاصد). Если ИИ применяется для дозволенного и полезного - он дозволен. Если для лжи, несправедливости, нарушения прав, запретного контента или обмана - его использование приобретает соответствующий запретный хукм. Сам по себе инструмент не имеет независимой религиозной оценки вне цели и способа применения.

3.3. Принцип предотвращения вреда (садд аз-зараи')

Правило «Вред должен быть устранен» (الضرر يزال) обязывает мусульманина избегать тех форм взаимодействия с ИИ, которые ослабляют веру, разрушают нравственность или причиняют вред людям: чрезмерной зависимости, замещения надежных религиозных источников случайными алгоритмическими ответами, слежки, манипуляции, создания запретного контента и распространения лжи.

3.4. Сохранение таваккуля и религиозной меры

Мусульманин обязан помнить, что ИИ - лишь одно из средств (асбаб), подчиненных воле Аллаха. Он может помочь искать, упорядочивать, рассчитывать и напоминать, но не заменяет дуа, истихару, шуру, обращение к Корану и Сунне и консультацию с надежными учеными в вопросах религии. Окончательное знание, мудрое руководство и абсолютная власть принадлежат только Аллаху.

Заключение

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

Вместе с тем отношение человека к ИИ может стать опасным для его веры: через чрезмерное упование, делегирование морального суждения, безусловное подчинение алгоритмическим выводам, гафлю и принятие ложных идеологий, противоречащих откровению. Опасность исходит не от «сущности машины», а от того места, которое человек отводит ей в своем сердце и мировоззрении.

Мудрость верующего состоит в том, чтобы пользоваться дозволенными благами этого мира, не становясь их рабом. Всевышний Аллах сказал:

هو الذي جعل لكم الأرض ذلولا فامشوا في مناكبها

«Он - Тот, Кто сделал для вас землю покорной. Ступайте же по ее просторам и питайтесь Его уделом» Сура Аль-Мульк, 67:15

Земля и все, что на ней, включая технологии, даны человеку в пользование и испытание. Задача верующего - использовать эти средства по шариату, сохраняя сердце привязанным к Творцу, а не к творению.

واللهأعلم- Аллах знает лучше

Источники

1. Коран аль-Карим.

2. Ибн аль-Каййим аль-Джаузийя. «Иълям аль-Муваккы'ин ан Рабб аль-'аламин».

3. Ибн аль-Каййим аль-Джаузийя. «Мадаридж ас-Саликин».

4. Ибн Таймийя. «Маджму' аль-Фатава».

5. Ас-Суюти. «Аль-Ашбах ва-н-Назаир».

6. Мухаммад ибн Абд аль-Ваххаб. «Аль-Усул ас-Саляса» и комментарии по теме тагута.

7. Аль-Газали. «Ихья' 'Улюм ад-Дин».

8. Ат-Тирмизи. «Сунан ат-Тирмизи» (хадис Ади ибн Хатима к аяту 9:31).

9. Ибн Касир. Тафсир к аятам 2:256, 9:31, 12:40 и 27:65.

Общая картина: IT-рынок Казахстана в 2025 году

IT-сектор в Казахстане растёт стремительно. Объём оказанных IT-услуг в 2024 году превысил 1,7 трлн тенге — в 2,7 раза больше, чем в 2021 году (данные Бюро национальной статистики). К концу июня 2025 года в стране насчитывалось 19,5 тыс. программистов, разработчиков и AI-специалистов, а количество IT-компаний за три года выросло на 16% — до 18 683 (Ranking.kz, Astana Hub).

При этом 2025 год стал годом «осторожного баланса» на рынке труда — без резких обвалов, но и без прежнего оптимизма.

Вакансий стало немного меньше. За 2025 год на hh.kz было размещено более 538 тысяч активных вакансий (все отрасли) — на 4,7% меньше, чем в 2024-м. При этом в IT ситуация неоднородная: в Q1 2025 прирост IT-вакансий составил +27,2% к Q1 2024, но к третьему кварталу рынок замедлился (hh.kz).

Конкуренция в IT остаётся высокой. В Q1 2025 на одну IT-вакансию приходилось в среднем 8,8 резюме (против 9,4 годом ранее). По классификации hh.kz, уровень 8,0–11,9 — это «высокая конкуренция». Для многих IT-специализаций индекс превышает 12 — это уже «крайне высокая конкуренция» (Ranking.kz).

Зарплаты в IT растут, но с замедлением. По данным Kolesa Group, за период с 2021 по 2024 год зарплаты в казахстанском IT выросли на 40%. По данным БНС, средняя номинальная зарплата в категории «Компьютерное программирование» достигла 1,2 млн тенге во втором квартале 2025 года. Медианная зарплата в IT по данным techinterview.space — 700 000 тенге (по 2 859 анкетам на начало 2025), средняя — 838 000 тенге. При этом hh.kz фиксирует, что медианная зарплата в IT снизилась, несмотря на рост числа вакансий — вероятно, из-за расширения спроса за счёт менее опытных специалистов (DKNews.kz).

Общий рынок труда Казахстана: медианная предлагаемая зарплата по стране — 268 970 тенге (Q3 2025, hh.kz), средняя номинальная — 423 133 тенге (Q1 2025, БНС). IT-специалисты зарабатывают в среднем в 3 раза больше среднего по стране.

Системный аналитик в Казахстане: конкуренция и спрос

На этом фоне роль SA занимает специфическое положение.

Конкуренция среди SA — на пороге «крайне высокой». По данным hh.kz за Q1 2025, индекс конкуренции для системных аналитиков составляет 13 резюме на 1 вакансию. Это зона «крайне высокой конкуренции» (≥12). Для сравнения — у программистов/разработчиков индекс 10, у DevOps — 12, у дизайнеров — 7.

Полная таблица конкуренции по аналитическим и смежным ролям (hh.kz, Q1 2025):

SA находится ровно на границе — рядом с бизнес-аналитиками и DevOps, ниже дата-сайентистов и BI-аналитиков, но выше разработчиков. Спрос есть, но и кандидатов хватает.

Кто нанимает SA в Казахстане. Среди активных работодателей на hh.kz и других площадках: банки (Халык Банк, Zaman Bank), телеком (Tele2/Altel), горнодобывающий сектор (ERG через BTS), финтех, e-gov и системные интеграторы (X NET, Prime Source, QazX). Финтех и банки — основной драйвер спроса на SA.

Зарплаты SA в Казахстане

Прямых зарплатных исследований, посвящённых именно системным аналитикам в Казахстане, немного — рынок компактнее российского, и SA часто объединяют в общую категорию «аналитиков». Но данные из нескольких источников позволяют собрать картину.

ГородРабот.kz: средняя зарплата по вакансиям SA — 975 000 тенге, диапазон — от 500 000 до 1 400 000 тенге.

Mojazarplata.kz (WageIndicator): большинство SA получают от 325 149 до 933 176 тенге в месяц. Начальный уровень — от 325 149 до 773 615 тенге. После 5 лет опыта — от 365 017 до 883 630 тенге.

Kolesa Group (исследование аналитиков 2025, 318 респондентов): средняя зарплата по направлению «аналитика данных (системная, бизнес-, риск- и маркетинговая)» — 1 000 000 тенге, медиана — 780 000 тенге, максимум — 3 100 000 тенге.

hh.kz (предлагаемые зарплаты в IT по опыту, Q1 2025):

Это данные по всей IT-сфере, но они релевантны и для SA. Грейдовая ориентировка для системных аналитиков, исходя из совокупности источников:

SA зарабатывает в 2–3 раза больше медианной зарплаты по стране (268 970 ₸). Зарплаты росли на 7–10% год к году, но темп замедляется.

Как трансформируется роль SA в Казахстане

1. Финтех и банки задают стандарт

Казахстанский рынок SA исторически плотно связан с финансовым сектором. По данным Kolesa Group, 47% аналитиков в стране работают в финтех-компаниях, и эта доля выросла на 17% с 2021 года. Банки (Халык, Kaspi, Forte, Jusan) и финтех-стартапы — основные заказчики системного анализа. Это формирует специфический стек требований: интеграции с платёжными системами, проект цифрового тенге, AML-процессы, банковские API.

2. Стек расширяется в сторону интеграций и микросервисов

В вакансиях SA на казахстанском рынке стандартный набор: SQL, BPMN, UML, REST, SOAP, Kafka, RabbitMQ, PostgreSQL, Oracle. В описаниях всё чаще встречаются требования по проектированию API, работе с брокерами сообщений и документированию интеграционных потоков. Это совпадает с глобальным трендом перехода от монолитных систем к микросервисным архитектурам.

3. Границы роли размываются — и это специфика КЗ

На казахстанском рынке роль SA часто совмещается с бизнес-аналитикой. В вакансиях регулярно встречается формулировка «системный/бизнес-аналитик» или «fullstack аналитик». Zaman Bank ищет «fullstack аналитика: от идеи до реализации». ERG нанимает «аналитика с навыками prompt engineer». Это отражает компактность казахстанских IT-команд: в отличие от крупных российских enterprise-структур, здесь один человек часто закрывает несколько аналитических функций.

С одной стороны, это расширяет зону ответственности и повышает ценность специалиста. С другой — усложняет позиционирование: если ты «всё и сразу», сложнее расти в глубину.

4. Международные компании меняют рынок

Доля специалистов, работающих в международных компаниях с офисами в Казахстане, выросла с 7% до 14% (Kolesa Group). Зарплаты в зарубежных компаниях в среднем в 2 раза выше локального рынка. Медианная зарплата на удалёнке для международных компаний — 1 400 000 тенге (techinterview.space). Это создаёт конкуренцию за senior-специалистов: локальные компании вынуждены подтягивать вилки, чтобы удерживать людей.

5. Алматы и Астана — два разных рынка

48% IT-резюме приходится на Алматы, 26,5% — на Астану (hh.kz, Q1 2025). Астана при этом показывает самый высокий прирост вакансий (+34% год к году в Q1 2025) — во многом благодаря госсектору и Astana Hub. Алматы остаётся центром частного IT: финтех, продуктовые компании, международные офисы. Для SA это означает два разных мира: в Астане больше e-gov и госпроектов с формализованными требованиями, в Алматы — продуктовая разработка с акцентом на скорость и гибкость.

6. Удалёнка уходит, гибрид приходит

По данным Kolesa Group, число IT-специалистов, работающих полностью удалённо, сократилось с 34% до 21%. Новая норма — гибридный формат. Для SA это существенно: работа аналитика предполагает плотное взаимодействие с бизнес-заказчиками, разработчиками и архитекторами — и многие компании считают, что это эффективнее в офлайне.

7. Конкуренция среди джуниоров высокая, дефицит — среди middle и senior

Казахстанский рынок насыщен начинающими специалистами: доля молодых (26–30 лет) выросла на 15% (Kolesa Group). Но компании ищут уровень middle и senior. Наибольший дефицит — в специализированных ролях: ML-инженеры, кибербезопасность, DevOps, а также сильные SA с опытом в сложных интеграциях. Для джунов путь в профессию сложнее, но для опытных специалистов рынок остаётся открытым.

Сводная таблица: SA в Казахстане в цифрах

Итог

Казахстанский IT-рынок находится в фазе быстрого роста — объём отрасли вырос в 2,7 раза за четыре года, количество компаний и специалистов растёт. Но одновременно рынок труда входит в период «осторожного баланса»: вакансий по-прежнему много, зарплаты высокие, но конкуренция среди кандидатов усиливается, а темпы роста зарплат замедляются.

Для системных аналитиков это означает несколько вещей. Конкуренция на уровне 13 резюме на вакансию — это зона высокого давления, но не критического. Зарплаты SA в 2–3 раза превышают среднюю по стране и сопоставимы с зарплатами разработчиков. Финтех и банки остаются главным драйвером спроса. Стек сдвигается в сторону интеграций, микросервисов и event-driven архитектур. Границы роли размываются в сторону «fullstack аналитика» — и это одновременно возможность и вызов.

Для SA, который умеет работать на стыке бизнес-анализа, проектирования интеграций и архитектуры данных — казахстанский рынок остаётся одним из самых перспективных в регионе. Текущее замедление — это не конец роста, а переход к более зрелой модели рынка, где ценится глубина экспертизы, а не просто наличие корочки.

Источники данных: hh.kz (обзоры Q1–Q3 2025, годовой итог 2025), Бюро национальной статистики РК, Kolesa Group (исследования data-профессий 2024–2025), techinterview.space, Ranking.kz, Astana Hub, DKNews.kz, Mojazarplata.kz, ГородРабот.kz. Все зарплаты указаны gross (до налогов), если не указано иное.

Ссылка на официальный проект закона (на казахском языке) - https://mazhilis.parlam.kz/ru/all-bill/759

Файл с проектом закона на русском - https://docs.google.com/document/d/1apAnQ1sQ-7jTYI7rFXP18WIkQLrdBqFO/edit?usp=sharing&ouid=117663469552766525529&rtpof=true&sd=true

1. Определение и сфера применения: Риск «регуляторной ловушки»

• Проблема, как она сформулирована в законе: Закон определяет искусственный интеллект как технологию, «позволяющую имитировать или превосходить когнитивные функции человека…».
• Анализ риска: Эта формулировка, апеллирующая к «подобию человеку», является не технической, а философской. Она создаёт огромную неопределённость. С одной стороны, под неё могут попасть даже сложные калькуляторы или поисковые системы, которые «имитируют» счёт или поиск информации. С другой стороны, разработчик сложной системы, способной нанести вред, может заявить, что она не «имитирует человека», а решает узкую математическую задачу, и таким образом избежать ответственности. Это создаёт правовую лазейку и делает применение закона непредсказуемым как для бизнеса, так и для граждан.
• Предлагаемое решение и его обоснование:
• На уровне Закона: Необходимо отказаться от «имитации человека» и закрепить функциональное определение. Например: «Система ИИ — система обработки данных, использующая обучаемые или эвристические модели для автономного или полуавтономного формирования выводов, оказывающих влияние на решения или действия в заявленной области».

Почему это важно? Такое определение фокусируется не на том, на что похожа система, а на том, что она делает и как влияет на реальный мир. Это делает закон технологически нейтральным, более стабильным во времени и позволяет чётко определить, какие системы подпадают под его действие.

• На уровне подзаконных актов: Разработать чек-листы и руководства с конкретными примерами и пограничными случаями, чтобы помочь разработчикам и надзорным органам однозначно классифицировать технологии.

2. Риск-ориентированный подход: «Классификация без последствий»

• Проблема, как она сформулирована в законе: Закон вводит правильную классификацию систем по уровням риска — минимальный, средний и высокий. Однако он не устанавливает, какие конкретные обязательства наступают для владельца системы в каждом из этих случаев.
• Анализ риска: Отсутствие прямой связки «класс риска → набор обязательств» делает всю систему неработоспособной. Для владельца системы «высокого риска» неясно, что именно он должен делать: проводить оценку воздействия на права человека (DPIA/AIA)? Осуществлять аудит на предвзятость? Страховать ответственность? Эта неопределённость создаёт поле для «ручного управления» со стороны регулятора, который сможет предъявлять произвольные требования, и повышает коррупционные риски.
• Предлагаемое решение и его обоснование:
• На уровне Закона: Внедрить матрицу обязанностей. Это таблица, где для каждого класса риска прописан минимальный набор обязательных действий. Например, для высокого риска это должно включать: обязательную предварительную оценку воздействия (DPIA/AIA), план негативных испытаний, ведение журнала инцидентов, обязательное страхование и создание канала для подачи жалоб.

Почему это важно? Это создаёт предсказуемые и прозрачные «правила игры», понятные всем участникам рынка. Бизнес получает чёткий чек-лист для соблюдения закона, а общество — гарантии безопасности для самых опасных систем.

• На уровне подзаконных актов: Утвердить методики проведения оценки рисков, формы отчётов (DPIA/AIA) и критерии аккредитации независимых аудиторов.

3. Национальный оператор и данные: Риск монополии и злоупотреблений

• Проблема, как она сформулирована в законе: Закон гласит, что «Правительство Республики Казахстан определяет оператора национальной платформы искусственного интеллекта», который получает доступ к данным госорганов и оказывает услуги.
• Анализ риска: Назначение единого оператора без конкурса и чётких правил доступа — это прямой путь к монополии и коррупции. Такой оператор может устанавливать завышенные тарифы, предоставлять привилегированный доступ «своим» компаниям и отказывать неугодным. Централизация огромных массивов данных, включая государственные, в одних руках без прописанных в законе механизмов внешнего контроля создаёт колоссальную угрозу приватности и национальной безопасности в случае утечки или злоупотребления.
• Предлагаемое решение и его обоснование:
• На уровне Закона: Закрепить незыблемые принципы: обязательный открытый конкурс для выбора оператора; недискриминационный и равный доступ к платформе и данным для всех участников; обязательное логирование (журналирование) всех операций по доступу к данным и создание публичного реестра таких передач.

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

• На уровне подзаконных актов: Утвердить конкретные условия конкурсов, типовые соглашения об уровне обслуживания (SLA), технические протоколы доступа и форматы логов.

4. Запреты и исключения: Риск «законной» слежки

• Проблема, как она сформулирована в законе: Закон запрещает удалённую биометрическую идентификацию в реальном времени, но с оговоркой: «за исключением случаев, определенных законами Республики Казахстан».
• Анализ риска: Эта формулировка является «широкой оговоркой», которая может полностью нивелировать сам запрет. С её помощью можно через другие, менее публично обсуждаемые законы, легитимизировать практически любую форму массового наблюдения, что представляет прямую угрозу базовым конституционным правам граждан на частную жизнь.
• Предлагаемое решение и его обоснование:
• На уровне Закона: Максимально сузить и конкретизировать исключения. Применение таких технологий должно быть возможно только при соблюдении совокупности строгих условий: доказанная острая необходимость и соразмерность угрозе; предварительное разрешение суда или независимого органа; чёткое ограничение по цели, месту и времени; обязательное ведение технических логов и, где это возможно, уведомление граждан постфактум.

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

• На уровне подзаконных актов: Разработать технические протоколы для таких систем, требования к их точности и порядку хранения логов.

5. Ответственность и возмещение вреда: Риск безнаказанности

• Проблема, как она сформулирована в законе: Закон отсылает к общему порядку Гражданского кодекса и делает страхование добровольным.
• Анализ риска: Для сложных систем ИИ доказать в суде причинно-следственную связь между действиями разработчика и наступившим вредом практически невозможно. Это оставляет пострадавшего без реальной возможности получить компенсацию. Отсутствие обязательного страхования лишает разработчиков систем высокого риска (например, в медицине или на транспорте) экономического стимула инвестировать в максимальную безопасность.
• Предлагаемое решение и его обоснование:
• На уровне Закона: Ввести обязательное страхование ответственности или предоставление иных финансовых гарантий для систем ИИ, отнесённых к категории высокого риска.

Почему это важно? Это создаёт гарантийный фонд, из которого пострадавшие смогут получить компенсацию, и одновременно заставляет рынок (через страховые тарифы) более строго оценивать реальные риски технологий, стимулируя разработчиков повышать безопасность своих продуктов.

• На уровне подзаконных актов: Определить минимальные лимиты страхового покрытия, перечень типовых страховых случаев и порядок урегулирования споров.

6. Права человека: Риск «цифрового бесправия»

• Проблема, как она сформулирована в законе: Закон упоминает право граждан «быть информированным», но не даёт конкретных инструментов для защиты своих прав.
• Анализ риска: Если алгоритм банка отказал вам в кредите, а система отбора кадров отклонила ваше резюме, простого информирования об этом недостаточно. Без права на объяснение и пересмотр человек оказывается в ситуации «цифрового бесправия», не имея возможности оспорить потенциально ошибочное, предвзятое или дискриминационное решение машины.
• Предлагаемое решение и его обоснование:
• На уровне Закона: Чётко закрепить пакет прав граждан при взаимодействии с системами ИИ, оказывающими значимое воздействие: право на уведомление, право на получение понятного объяснения логики решения, право на человеческий пересмотр и право на подачу жалобы по ясной процедуре.

Почему это важно? Это возвращает человеку контроль и субъектность в цифровом мире, создавая механизм подотчётности для автоматизированных систем и защищая от произвола «чёрного ящика».

• На уровне подзаконных актов: Разработать стандарты качества объяснений, определить критерии «значимого воздействия» и установить конкретные сроки и форматы рассмотрения жалоб.

Итоговая таблица предложений по доработке Закона

Учебные цели курса

Общая цель

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

Конкретные цели обучения

По завершении курса слушатели будут способны:

1. Знать и понимать:
• Актуальную нормативно-правовую базу, регулирующую разработку и реализацию ГИП в сфере информатизации
• Структуру и содержание инвестиционного предложения и технического задания
• Критерии оценки ГИП при проведении экспертизы
• Процедуры согласования и утверждения документации
2. Уметь применять:
• Методики анализа текущего состояния информационных систем
• Техники обоснования необходимости создания или развития объектов информатизации
• Инструменты расчета экономической эффективности ГИП
• Подходы к оценке и управлению рисками проекта
3. Владеть навыками:
• Разработки всех разделов инвестиционного предложения
• Составления технического задания на создание или развитие объектов информатизации
• Подготовки финансово-экономического обоснования
• Работы с архитектурным порталом "электронного правительства"
• Защиты проекта при прохождении экспертизы

Портрет целевой аудитории

Основные категории слушателей

1. Государственные служащие:
• Сотрудники ИТ-подразделений государственных органов
• Специалисты отделов стратегического планирования
• Сотрудники, ответственные за цифровизацию и информатизацию
• Руководители проектов по созданию и развитию информационных систем
2. Сотрудники квазигосударственного сектора:
• Специалисты ИТ-департаментов национальных компаний
• Менеджеры проектов по цифровой трансформации
• Сотрудники, ответственные за взаимодействие с государственными органами
3. Консультанты и эксперты:
• Специалисты консалтинговых компаний, оказывающих услуги по разработке ГИП
• Независимые эксперты в области информатизации
• Сотрудники компаний-разработчиков информационных систем для госсектора

Требования к начальному уровню подготовки

1. Базовые знания:
• Общее понимание процессов информатизации и цифровизации
• Базовые знания в области проектного управления
• Представление о бюджетном процессе в Республике Казахстан
2. Профессиональный опыт:
• Опыт работы в сфере информационных технологий или управления проектами (желательно)
• Участие в проектах по созданию или развитию информационных систем (желательно)

Профессиональные задачи слушателей

1. Инициирование и обоснование проектов по созданию или развитию информационных систем
2. Подготовка документации для получения бюджетного финансирования на ИТ-проекты
3. Взаимодействие с уполномоченными органами по вопросам согласования ГИП
4. Сопровождение проектов на этапе экспертизы и защиты
5. Мониторинг и оценка реализации ГИП в сфере информатизации

Ожидания слушателей от курса

1. Получение актуальных знаний о требованиях к ГИП в сфере информатизации
2. Освоение практических инструментов разработки инвестиционных предложений
3. Понимание критериев оценки проектов экспертными органами
4. Изучение успешных кейсов и типичных ошибок при разработке ГИП
5. Получение шаблонов и образцов документов для использования в работе

Структура и ключевые разделы ГИП для информационных систем в Казахстане

На основе анализа нормативных требований к государственным инвестиционным проектам (ГИП) в сфере информатизации в Казахстане, можно выделить следующую структуру и ключевые разделы документации:

1. Инвестиционное предложение (ИП)

1.1. Информационный лист инвестиционного предложения

• Приоритеты развития отрасли (сферы) экономики
• Соответствие документам Системы государственного планирования РК
• Цели и задачи проекта
• Обоснование необходимости реализации проекта

1.2. Анализ текущего состояния

• Анализ текущего состояния и потребностей государственных органов
• Анализ потребностей пользователей цифровых услуг
• Оценка существующих информационных систем и их взаимодействия
• Выявление проблем и недостатков текущего состояния

1.3. Технико-экономическое обоснование

• Расчет затрат на создание и развитие объекта информатизации
• Оценка экономической эффективности
• Анализ выгод и издержек
• Обоснование стоимости проекта

1.4. Оценка рисков

• Идентификация возможных рисков реализации проекта
• Меры по минимизации рисков
• План управления рисками

1.5. Заключение отраслевой экспертизы

• Оценка соответствия проекта приоритетам отрасли
• Оценка влияния реализации ГИП на курирующую отрасль
• Рекомендации отраслевого центрального государственного органа

2. Техническое задание (ТЗ)

2.1. Общие сведения

• Полное наименование системы и ее условное обозначение
• Основание для разработки
• Назначение разработки
• Плановые сроки начала и окончания работ

2.2. Назначение и цели создания системы

• Назначение системы
• Цели создания системы
• Характеристика объекта автоматизации

2.3. Требования к системе

• Требования к системе в целом
• Требования к функциям системы
• Требования к видам обеспечения (информационному, программному, техническому)
• Требования к надежности, безопасности, эргономике
• Требования к совместимости с существующими системами

2.4. Состав и содержание работ

• Перечень стадий и этапов работ
• Сроки выполнения
• Перечень документов, предъявляемых по окончании работ

2.5. Порядок контроля и приемки системы

• Виды, состав и методы испытаний
• Общие требования к приемке работ

3. Процедуры согласования и экспертизы

3.1. Внесение документов через архитектурный портал

• Порядок оформления запросов в архитектурном портале
• Требования к электронным форматам документов
• Процедура цифрового согласования

3.2. Экспертиза в сфере информатизации

• Критерии оценки инвестиционных предложений
• Сроки проведения экспертизы
• Возможные результаты экспертизы

3.3. Экспертиза информационной безопасности

• Требования к обеспечению информационной безопасности
• Критерии оценки соответствия требованиям безопасности
• Процедура получения заключения по информационной безопасности

4. Финансово-экономическое обоснование (для ГИП, реализуемых через увеличение уставного капитала)

4.1. Финансовая модель проекта

• Расчет инвестиционных затрат
• Прогноз доходов и расходов
• Анализ окупаемости проекта

4.2. Источники финансирования

• Структура финансирования
• График финансирования по годам
• Обоснование объемов финансирования

5. Мониторинг и оценка реализации ГИП

5.1. Ключевые показатели эффективности

• Целевые индикаторы проекта
• Методика расчета показателей
• Периодичность мониторинга

5.2. Отчетность по реализации проекта

• Формы отчетности
• Сроки предоставления отчетности
• Ответственные лица и подразделения

Программа учебного курса "Разработка государственных инвестиционных проектов (ГИП) в сфере информатизации"

Общая информация

• Продолжительность курса: 40 академических часов (5 дней)
• Формат обучения: Очный/дистанционный с практическими занятиями
• Итоговая аттестация: Защита учебного проекта ГИП

Модуль 1. Нормативно-правовая база разработки ГИП в сфере информатизации (6 часов)

Тема 1.1. Законодательство Республики Казахстан в сфере информатизации (2 часа)

• Закон РК "Об информатизации"
• Бюджетный кодекс РК в части планирования государственных инвестиций
• Система государственного планирования РК
• Актуальные изменения в законодательстве (Правила планирования и реализации ГИП от 22 мая 2025 года)

Тема 1.2. Регламенты и процедуры разработки ГИП (2 часа)

• Правила разработки и корректировки инвестиционных предложений
• Правила проведения экспертизы в сфере информатизации
• Требования к составлению технических заданий на создание и развитие объектов информатизации
• Порядок согласования документации с уполномоченными органами

Тема 1.3. Роли и ответственность участников процесса (2 часа)

• Функции администратора бюджетных программ (АБП)
• Полномочия уполномоченного органа в сфере информатизации
• Роль отраслевых центральных государственных органов
• Взаимодействие с экспертными организациями

Модуль 2. Структура и содержание инвестиционного предложения (10 часов)

Тема 2.1. Информационный лист инвестиционного предложения (2 часа)

• Требования к оформлению информационного листа
• Обоснование соответствия приоритетам развития отрасли
• Формулировка целей и задач проекта
• Типичные ошибки при заполнении информационного листа

Тема 2.2. Анализ текущего состояния и обоснование необходимости проекта (3 часа)

• Методики анализа текущего состояния информационных систем
• Выявление и описание проблем, требующих решения
• Анализ потребностей пользователей цифровых услуг
• Обоснование необходимости создания или развития объекта информатизации
• Оценка завершенности ранее инициированных проектов на аналогичные цели

Тема 2.3. Технико-экономическое обоснование проекта (3 часа)

• Структура и содержание технико-экономического обоснования
• Методики расчета затрат на создание и развитие объектов информатизации
• Оценка экономической эффективности проекта
• Анализ выгод и издержек
• Обоснование стоимости проекта

Тема 2.4. Оценка и управление рисками проекта (2 часа)

• Идентификация рисков реализации ГИП в сфере информатизации
• Качественная и количественная оценка рисков
• Разработка мер по минимизации рисков
• Составление плана управления рисками

Модуль 3. Разработка технического задания для ГИП (8 часов)

Тема 3.1. Общие требования к техническому заданию (2 часа)

• Структура и содержание технического задания
• Нормативные требования к оформлению ТЗ
• Взаимосвязь ТЗ с инвестиционным предложением
• Типичные ошибки при составлении ТЗ

Тема 3.2. Функциональные требования к информационной системе (3 часа)

• Методики формулирования функциональных требований
• Описание автоматизируемых бизнес-процессов
• Требования к интерфейсам и режимам функционирования
• Требования к совместимости с существующими системами
• Требования к масштабируемости и развитию системы

Тема 3.3. Нефункциональные требования к информационной системе (3 часа)

• Требования к надежности и производительности
• Требования к информационной безопасности
• Требования к техническому и программному обеспечению
• Требования к эргономике и удобству использования
• Требования к документированию и сопровождению

Модуль 4. Процедуры согласования и экспертизы ГИП (6 часов)

Тема 4.1. Работа с архитектурным порталом "электронного правительства" (2 часа)

• Регистрация и авторизация на портале
• Заполнение электронных форм инвестиционного предложения и ТЗ
• Загрузка сопроводительной документации
• Отслеживание статуса рассмотрения документов

Тема 4.2. Экспертиза инвестиционных предложений (2 часа)

• Критерии оценки инвестиционных предложений
• Процедура проведения экспертизы
• Типичные замечания экспертов и способы их устранения
• Подготовка к защите проекта перед экспертной комиссией

Тема 4.3. Экспертиза в сфере информационной безопасности (2 часа)

• Требования к обеспечению информационной безопасности
• Процедура проведения экспертизы информационной безопасности
• Типичные замечания по вопросам безопасности
• Доработка проекта с учетом требований информационной безопасности

Модуль 5. Финансово-экономическое обоснование для ГИП (4 часа)

Тема 5.1. Структура и содержание финансово-экономического обоснования (2 часа)

• Требования к финансово-экономическому обоснованию
• Особенности ФЭО для проектов, реализуемых через увеличение уставного капитала
• Расчет инвестиционных затрат и операционных расходов
• Обоснование источников финансирования

Тема 5.2. Финансовая модель проекта (2 часа)

• Разработка финансовой модели ГИП
• Прогнозирование доходов и расходов
• Анализ окупаемости проекта
• Оценка эффективности инвестиций

Модуль 6. Практикум по разработке ГИП (6 часов)

Тема 6.1. Анализ успешных кейсов ГИП в сфере информатизации (2 часа)

• Обзор успешно реализованных проектов
• Анализ факторов успеха
• Извлеченные уроки и лучшие практики
• Адаптация успешного опыта к собственным проектам

Тема 6.2. Разбор типичных ошибок при разработке ГИП (2 часа)

• Анализ отклоненных проектов
• Типичные ошибки в инвестиционных предложениях
• Распространенные недостатки технических заданий
• Рекомендации по избеганию критических ошибок

Тема 6.3. Групповая работа над учебным проектом (2 часа)

• Формирование проектных команд
• Выбор темы учебного проекта
• Консультации по разработке проекта
• Подготовка к защите проекта

Итоговая аттестация и защита проектов (2 часа)

• Презентация разработанных учебных проектов ГИП
• Экспертная оценка проектов
• Обратная связь и рекомендации
• Подведение итогов курса и вручение сертификатов

Методическое обеспечение курса

• Учебные материалы (презентации, конспекты лекций)
• Шаблоны и образцы документов
• Нормативно-правовые акты
• Практические задания и кейсы
• Методические рекомендации по разработке ГИП
• Доступ к демо-версии архитектурного портала для практических занятий

Практические задания и кейсы для курса

"Разработка государственных инвестиционных проектов (ГИП) в сфере информатизации"

Практическое задание 1: Анализ нормативно-правовой базы

Цель задания: Научиться ориентироваться в законодательстве, регулирующем разработку ГИП в сфере информатизации.

Описание задания:

1. Разделитесь на группы по 3-4 человека.
2. Каждой группе предоставляется один из нормативных документов:
• Закон РК "Об информатизации"
• Правила планирования и реализации ГИП в сфере информатизации
• Правила проведения экспертизы в сфере информатизации
• Требования к составлению технических заданий
3. Проанализируйте документ и подготовьте краткую презентацию (5-7 минут), отражающую:
• Ключевые положения документа, относящиеся к разработке ГИП
• Требования и ограничения, которые необходимо учитывать
• Процедуры и сроки, установленные документом
4. Представьте результаты анализа другим группам.

Ожидаемый результат: Презентация и выступление по анализу нормативного документа.

Практическое задание 2: Разработка информационного листа инвестиционного предложения

Цель задания: Научиться составлять информационный лист инвестиционного предложения в соответствии с требованиями.

Описание задания:

1. На основе предложенного кейса (описание потребности в создании/развитии информационной системы) разработайте информационный лист инвестиционного предложения.
2. В информационном листе необходимо отразить:
• Наименование и цель проекта
• Соответствие приоритетам развития отрасли
• Обоснование необходимости реализации проекта
• Предварительную оценку стоимости проекта
• Ожидаемые результаты реализации проекта
3. Используйте официальную форму информационного листа.

Ожидаемый результат: Заполненный информационный лист инвестиционного предложения.

Практическое задание 3: Анализ текущего состояния и обоснование необходимости проекта

Цель задания: Научиться проводить анализ текущего состояния и формулировать обоснование необходимости проекта.

Описание задания:

1. На основе предложенного кейса (описание государственного органа и его информационных систем) проведите анализ текущего состояния:
• Опишите существующие информационные системы
• Выявите проблемы и недостатки текущего состояния
• Проанализируйте потребности пользователей
2. Сформулируйте обоснование необходимости создания/развития информационной системы:
• Опишите, какие проблемы будут решены
• Обоснуйте, почему существующие решения не удовлетворяют потребностям
• Укажите, как предлагаемый проект соотносится с ранее инициированными проектами

Ожидаемый результат: Аналитическая записка с анализом текущего состояния и обоснованием необходимости проекта.

Практическое задание 4: Разработка технико-экономического обоснования

Цель задания: Научиться разрабатывать технико-экономическое обоснование проекта.

Описание задания:

1. На основе предложенного кейса (описание проекта по созданию/развитию информационной системы) разработайте технико-экономическое обоснование:
• Рассчитайте затраты на создание/развитие системы
• Оцените экономическую эффективность проекта
• Проведите анализ выгод и издержек
• Обоснуйте стоимость проекта
2. Используйте предоставленные шаблоны и методики расчета.

Ожидаемый результат: Технико-экономическое обоснование проекта с расчетами.

Практическое задание 5: Оценка и управление рисками проекта

Цель задания: Научиться идентифицировать риски и разрабатывать меры по их минимизации.

Описание задания:

1. На основе предложенного кейса (описание проекта по созданию/развитию информационной системы):
• Идентифицируйте не менее 10 возможных рисков реализации проекта
• Проведите качественную оценку рисков (вероятность и влияние)
• Разработайте меры по минимизации каждого риска
• Составьте план управления рисками
2. Используйте предоставленную матрицу оценки рисков.

Ожидаемый результат: Реестр рисков проекта и план управления рисками.

Практическое задание 6: Разработка функциональных требований к информационной системе

Цель задания: Научиться формулировать функциональные требования к информационной системе.

Описание задания:

1. На основе предложенного кейса (описание бизнес-процессов, подлежащих автоматизации):
• Сформулируйте функциональные требования к информационной системе
• Опишите автоматизируемые бизнес-процессы
• Определите требования к интерфейсам и режимам функционирования
• Укажите требования к совместимости с существующими системами
2. Используйте предоставленный шаблон технического задания.

Ожидаемый результат: Раздел технического задания с функциональными требованиями.

Практическое задание 7: Работа с архитектурным порталом "электронного правительства"

Цель задания: Научиться работать с архитектурным порталом для подачи и отслеживания документов.

Описание задания:

1. В демо-версии архитектурного портала:
• Зарегистрируйтесь и авторизуйтесь
• Заполните электронные формы инвестиционного предложения
• Загрузите сопроводительную документацию
• Отследите статус рассмотрения документов
2. Выполните действия по исправлению замечаний (на основе предоставленного сценария).

Ожидаемый результат: Скриншоты выполненных действий и отчет о работе с порталом.

Кейс-стади 1: Анализ успешного ГИП "Единая система электронного документооборота государственных органов"

Цель: Изучить успешный опыт разработки и реализации ГИП в сфере информатизации.

Описание кейса:

1. Участникам предоставляется документация по успешно реализованному проекту "Единая система электронного документооборота государственных органов":
• Инвестиционное предложение
• Техническое задание
• Заключения экспертиз
• Отчеты о реализации проекта
2. Задание для групп:
• Проанализировать структуру и содержание документации
• Выявить факторы, способствовавшие успешному согласованию проекта
• Определить ключевые аргументы, использованные для обоснования необходимости проекта
• Оценить качество технико-экономического обоснования
3. Подготовить презентацию с анализом кейса и рекомендациями для собственных проектов.

Ожидаемый результат: Презентация с анализом успешного кейса и выводами для применения в собственной практике.

Кейс-стади 2: Анализ отклоненного ГИП "Система мониторинга общественного транспорта"

Цель: Изучить типичные ошибки при разработке ГИП и способы их избежать.

Описание кейса:

1. Участникам предоставляется документация по отклоненному проекту "Система мониторинга общественного транспорта":
• Инвестиционное предложение
• Техническое задание
• Отрицательные заключения экспертиз с замечаниями
2. Задание для групп:
• Проанализировать замечания экспертов
• Выявить ключевые ошибки в документации
• Предложить варианты исправления выявленных недостатков
• Разработать план доработки проекта для повторной подачи
3. Подготовить презентацию с анализом ошибок и предложениями по их исправлению.

Ожидаемый результат: Презентация с анализом ошибок и планом доработки проекта.

Кейс-стади 3: Защита ГИП перед экспертной комиссией

Цель: Отработать навыки защиты проекта перед экспертной комиссией.

Описание кейса:

1. Участники разделяются на группы:
• Команда разработчиков ГИП
• Экспертная комиссия
2. Команде разработчиков предоставляется документация по проекту "Система электронных государственных закупок":
• Инвестиционное предложение
• Техническое задание
• Презентация проекта
3. Задание для команды разработчиков:
• Изучить документацию
• Подготовить выступление для защиты проекта (10 минут)
• Ответить на вопросы экспертной комиссии
4. Задание для экспертной комиссии:
• Изучить документацию
• Подготовить вопросы по проекту
• Оценить выступление команды разработчиков
5. После завершения ролевой игры проводится общее обсуждение и анализ.

Ожидаемый результат: Проведение ролевой игры по защите проекта и анализ результатов.

Итоговый проект: Разработка полного комплекта документации ГИП

Цель: Применить полученные знания и навыки для разработки полного комплекта документации ГИП.

Описание проекта:

1. Участники разделяются на проектные команды по 3-4 человека.
2. Каждая команда выбирает тему проекта из предложенного списка или предлагает свою тему:
• Система электронного лицензирования
• Портал открытых данных
• Система мониторинга качества государственных услуг
• Единая система учета государственного имущества
• Система электронного здравоохранения
3. Команды разрабатывают полный комплект документации ГИП:
• Информационный лист инвестиционного предложения
• Анализ текущего состояния и обоснование необходимости проекта
• Технико-экономическое обоснование
• Оценка рисков проекта
• Техническое задание (основные разделы)
4. В течение курса проводятся консультации по разработке проекта.
5. В конце курса команды защищают свои проекты перед экспертной комиссией.

Ожидаемый результат: Полный комплект документации ГИП и его защита.

1. Введение
• Кратко о бизнес-правилах и их изучении в практическом курсе.
• Возможность записи на курс со скидкой.
2. Проблемы в работе с бизнес-информацией
• Неполнота данных, избыточность, противоречия.
• Начинающие аналитики часто не замечают пробелы в информации.
3. Пример бизнес-процесса (кредитование)
• Описание процесса рассмотрения заявок на кредит:
• Каналы подачи (интернет, офис).
• Проверка кредитной истории, дохода, DTI (Debt-to-Income).
• Критерии принятия решений (возраст, сумма кредита и т. д.).
• Выделение повторяющихся логических конструкций и типовых решений.
4. Определение бизнес-правил
• Общие определения:
• Набор критериев для управления бизнесом.
• Правила, определяющие, что можно/нельзя делать, или условия принятия решений.
• Классификации:
• Рональд Росс:
• Определяющие правила (связи между концепциями).
• Поведенческие правила (управление действиями).
• Карл Вигерс:
• Утверждения, ограничивающие или определяющие аспекты деятельности организации.
5. Формализация бизнес-правил
• Простые правила: if X, then Y (например, "если кредитная история плохая → отказ").
• Сложные (многокритериальные) правила: комбинации условий (if X и Y и Z, then A).
• Таблицы принятия решений (Decision Tables):
• Столбцы: критерии.
• Строки: комбинации значений и соответствующие решения.
• Преимущества: наглядность, выявление пропущенных комбинаций.
6. Проблемы и риски
• Пропущенные комбинации критериев → неполные требования → ошибки в системе.
• Необходимость проверки полноты таблиц (например, через декартово произведение значений критериев).
7. Практический курс по бизнес-анализу
• 11 модулей: от концепций бизнеса до спецификаций требований.
• Примеры тем: моделирование сущностей, диаграммы UML, проектирование интерфейсов.

Часть 2: Использование Generative AI (Алеся)

1. Роль Generative AI в бизнес-анализе
• Помощь в структурировании информации, анализе логики, генерации артефактов.
• Использование как ассистента для Discovery и автоматизации рутинных задач.
2. Типы задач для AI
• Моделирование сценариев, выявление исключений, валидация бизнес-правил.
• Визуализация логики (например, диаграммы решений).
3. Работа с ChatGPT: лучшие практики
• Контекст: Четко обозначайте роль (например, "ты опытный бизнес-аналитик").
• Итеративность: Разбивайте запросы на шаги (от общего к частному).
• Примеры: Показывайте образцы желаемого результата (например, "сделай таблицу, как здесь").
• Проверка: Учитывайте "галлюцинации" AI — всегда перепроверяйте факты.
4. Демонстрация: извлечение бизнес-правил из текста
• Шаг 1: Анализ текста → выделение бизнес-логики.
• Шаг 2: Поиск пробелов/противоречий.
• Шаг 3: Формулировка вопросов к заказчику.
• Шаг 4: Генерация эталонной логики.
• Шаг 5: Создание Decision Table и диаграммы (например, в Mermaid).
5. Ограничения AI
• Конфиденциальность: анонимизируйте данные перед загрузкой.
• "Галлюцинации": запрашивайте источники информации.
• Нестабильность ответов: перезапускайте диалог при некорректных результатах.

Ключевые выводы

• Бизнес-правила — основа для корректных требований. Их пропуск ведет к ошибкам в системе.
• Generative AI ускоряет анализ, но требует контроля и четких инструкций.
• Инструменты вроде Decision Tables и Mermaid-диаграмм помогают визуализировать логику.

Дополнительные материалы: Презентация, промты и записи будут отправлены на email участников.

Ссылки:

• Telegram-группа для записи на курс: QR-код в презентации.
• LinkedIn Алеси и Александра — анонсы новых воркшопов.

Ссылка - https://www.youtube.com/watch?v=iHQxkNjgPGg&ab_channel=AlexanderBelin

• Государство -> Гражданин: Если применять буквально, то государство должно было бы обращаться с данными граждан так же, как граждане обращаются с "данными государства" (например, с гостайной) или с данными друг друга. Это проблематичная логика, так как государство само устанавливает правила и имеет иные функции и права (например, на сбор налоговой информации), чем гражданин. Скорее, это может проявляться в международных отношениях (зеркальные ответы на кибератаки, шпионаж, требования к данным).
• Гражданин -> Государство: Если гражданин чувствует, что государство массово и непрозрачно собирает его данные, нарушает его приватность, то по этой максиме он может считать для себя оправданным зеркально не уважать "приватность" государства – скрывать доходы, уклоняться от предоставления информации, использовать анонимные сети, считая, что он лишь отвечает тем же на действия государства. Это может приводить к оправданию противоправного поведения.

2. "Не поступай с другими так, как они не ведут себя по отношению к тебе." (Этика Не-Проактивности / Ограниченного Доверия)

• Государство -> Гражданин: Если граждане активно не требуют повышенной защиты своих данных, не возражают против определенных видов сбора информации (или не имеют механизмов для этого), то государство, следуя этой максиме, не будет по своей инициативе внедрять более строгие меры приватности, чем те, которые оно "видит" или которые у него требуют. "Раз они не просят защищать их лучше, мы и не будем".
• Гражданин -> Государство: Если государство не демонстрирует прозрачности в своих действиях и сборе данных, гражданин не будет добровольно предоставлять о себе больше информации, чем абсолютно необходимо по закону. "Вы не открыты со мной – и я не буду делать шагов навстречу вам, которых вы не делаете".

3. "Не мешай другим поступать с тобой так, как ты сам поступаешь с ними." (Этика Последовательности / Принятия Ответственности)

• Государство -> Гражданин: Если государство активно собирает данные, проводит проверки, требует отчетности (т.е. определенным образом "поступает" с гражданами), оно не должно мешать (например, законодательно ограничивать или преследовать) гражданам, СМИ, НПО осуществлять общественный контроль, собирать информацию о деятельности госорганов, требовать отчетности (т.е. поступать с государством так же, как оно поступает с ними в плане контроля). Подразумевает открытость к критике и мониторингу.
• Гражданин -> Государство: Если гражданин ведет себя непрозрачно по отношению к государству (скрывает доходы, предоставляет ложные сведения), он не должен мешать государству применять к нему ответные меры контроля и проверки (т.е. поступать с ним так же – с недоверием и проверкой – как он поступает с государством). Подразумевает принятие последствий своего поведения.

4. "Не давай другим поступать с тобой так, как ты с ними не поступаешь." (Этика Установления Границ / Требования Взаимности)

• Государство -> Гражданин: Если государство само не практикует тотальную слежку и уважает базовые права граждан на частную жизнь, то оно должно "не давать" / активно защищать своих граждан от подобного вмешательства со стороны других акторов (иностранных спецслужб, возможно, крупных корпораций, криминала). Государство выступает гарантом приватности, которую само же соблюдает.
• Гражданин -> Государство: Если гражданин выполняет свои законные обязанности по предоставлению информации государству честно и в установленном объеме (т.е. "не поступает плохо" с государством в этом аспекте), он должен "не давать" государству поступать с ним так, как он с ним не поступает – то есть, требовать защиты своей приватности, оспаривать незаконный сбор данных, требовать прозрачности, устанавливать границы дозволенного для государства через законы, суды, общественные институты. Это максима, лежащая в основе защиты прав человека от произвола власти.

• Принцип: Аналитик обращается с конфиденциальными данными так, как это принято в его ближайшем окружении (команде, отделе), даже если это не полностью соответствует официальным политикам или лучшим практикам.
• Поведение:
• Если в команде принято пересылать данные клиентов во внутренних чатах без шифрования или хранить тестовые данные с реальными ФИО на общих дисках, потому что "все так делают и быстрее", этот аналитик будет поступать так же.
• Не будет задавать вопросов о необходимости сбора определенных персональных данных, если их сбор является стандартной практикой в компании, даже если не видит явной цели.
• Уровень защиты данных определяется не политиками или законом, а неформальной нормой группы.
• Риски: Высокая вероятность утечек данных, нарушения законодательства (например, GDPR или местного закона о персданных), потеря доверия клиентов, штрафы для компании.

2. Этика Осторожности / Минимализма в Защите Данных (по принципу "Не делай того, что другие не делают"):

• Принцип: Аналитик не будет внедрять или требовать мер по защите данных, которые превышают минимально принятый в его окружении уровень, даже если они рекомендованы стандартами безопасности или здравым смыслом.
• Поведение:
• Если никто в команде не занимается анонимизацией данных для разработки или тестирования (хотя это лучшая практика), он не будет настаивать на этом.
• Не будет предлагать использовать шифрование для определенных полей в базе данных, если это "никто раньше не делал и не требовал".
• Избегает проведения оценки влияния на конфиденциальность (Privacy Impact Assessment), если это не является строго обязательной и повсеместной процедурой.
• Будет реализовывать только те меры защиты, которые явно прописаны в самых базовых инструкциях или которые делают все остальные.
• Риски: Упускаются возможности для повышения уровня защиты данных, система может соответствовать лишь минимальным (возможно, устаревшим) требованиям, игнорируются проактивные меры безопасности.

3. Этика Навязывания Собственных Стандартов Данных (по принципу "Все должны делать то, что делаю я"):

• Принцип: Аналитик имеет свое (возможно, верное, а возможно, и нет) представление о "правильной" работе с конфиденциальными данными и требует от всех (разработчиков, тестировщиков, коллег) неукоснительного следования именно его подходу.
• Поведение:
• Если аналитик параноидально относится к безопасности, он может требовать избыточных мер защиты, шифрования всего и вся, максимального ограничения доступа, что может неоправданно усложнять и замедлять работу команды.
• Если же он, наоборот, считает меры безопасности излишними, он может настаивать на упрощенном доступе к данным для "удобства", критиковать коллег за "бюрократию" при запросе доступа, требовать хранения данных в незащищенном виде, потому что ему так проще анализировать.
• Отвергает альтернативные подходы к защите данных, если они не совпадают с его личным методом.
• Риски: Либо создание неоправданных барьеров и замедление работы, либо создание дыр в безопасности – в зависимости от личных установок аналитика. Конфликты в команде.

4. Этика Запрета на Использование / Доступ к Данным (по принципу "Никто не должен делать того, чего не делаю я"):

• Принцип: Аналитик активно препятствует использованию или доступу к данным другими сотрудниками/системами способами, которые он сам не практикует или считает ненужными/небезопасными, даже если это требуется для работы и соответствует политикам.
• Поведение:
• Отказывается предоставлять разработчикам или тестировщикам необходимые (возможно, анонимизированные) данные, потому что "я считаю, что им это не нужно" или "я бы так не делал".
• Блокирует требования на интеграцию с другой системой для обмена данными, потому что лично не доверяет той системе или не хочет разбираться в вопросах безопасности передачи.
• Препятствует внедрению аналитических инструментов, которые работают с пользовательскими данными (даже агрегированными), если сам такими инструментами не пользуется или не понимает их ценности/рисков.
• Становится "сторожевым псом" данных, руководствуясь личными соображениями, а не объективной необходимостью и правилами.
• Риски: Блокировка необходимой работы, замедление разработки и анализа, создание информационных "колодцев", принятие решений на основе неполных данных из-за искусственных ограничений.

Версия 2.0 - https://drive.google.com/file/d/1rUHJIvtm4ICnU3iDmCMnRKfEM420Ffrw/view?usp=drive_link

Версия 1.0 - https://drive.google.com/file/d/1vfup61je2eS4PrPPBzRcZvIoEoR972RP/view?usp=sharing

Сравнение структуры разделов в версиях 1.0 и 2.0 документа "The Business Analysis Standard":

Версия 1.0

1. Preface: Введение в стандарт, объяснение его эволюции, краткое описание изменений и информация о IIBA.
2. Chapter 1: Understanding Business Analysis: Определение бизнес-анализа, его важность и введение модели BACCM™.
3. Chapter 2: Mindset for Effective Business Analysis: Обсуждение важности мышления, принципов и подходов к бизнес-анализу.
4. Chapter 3: Performing Business Analysis: Кто выполняет бизнес-анализ, подходы (предсказуемые, адаптивные, гибридные), ценность, ключевые компетенции и техники, организационные аспекты (устойчивость, DEI), управление доставкой.
5. Chapter 4: Tasks and Knowledge Areas: 30 задач бизнес-анализа, сгруппированных в шесть областей знаний.
6. Chapter 5: Summary: Краткое изложение ключевых аспектов стандарта.
7. Chapter 6: Glossary and Key Terms: Определения ключевых терминов.
8. Chapter 7: Contributors: Список участников и организаций, внесших вклад в стандарт.
9. Back Cover: Краткий обзор стандарта и информация о публикациях IIBA.

Версия 2.0

1. Preface: Включает краткое резюме, улучшенное для быстрого ознакомления.
2. Chapter 1: Introducing the Business Analysis Standard: Введение в стандарт, включая его определение, вклад сообщества и необходимость стандарта.
3. Chapter 2: Understanding Business Analysis: Расширенное определение бизнес-анализа, включая BACCM™ как модель мышления и организации.
4. Chapter 3: Mindset for Effective Business Analysis: Углубленный акцент на мышлении, принципах и компетенциях.
5. Chapter 4: Performing Business Analysis: Подходы (предсказуемые, адаптивные, гибридные), ценность, техники, организационные аспекты (включая безопасность, этику, устойчивость).
6. Chapter 5: Tasks and Knowledge Areas: Основное внимание уделено 30 задачам бизнес-анализа, представленных в формате "карточек задач".
7. Glossary and Key Terms: Расширенный глоссарий, связанный с BABOK Guide, перенесено в Knowledge Hub для упрощения документа.
8. Contributors: Перенесено в Knowledge Hub для упрощения документа.

Основные отличия:

1. Новые разделы:
• Chapter 1: Introducing the Business Analysis Standard.
• Раздел "Applying Business Analysis Tasks" заменяет "Tasks and Knowledge Areas" из версии 1.0.
2. Glossary и Contributors:
• В версии 1.0 эти разделы включены в документ.
• В версии 2.0 они перенесены в KnowledgeHub.
3. Фокус на задачах:
• В версии 2.0 задачи представлены в формате "карточек задач" с акцентом на практическое применение.
4. Улучшение структуры:
• Версия 2.0 имеет более логичную организацию с нумерованными заголовками и улучшенной читаемостью.

Сравнение раздела "Preface" в версиях 1.0 и 2.0 документа "The Business Analysis Standard":

Версия 1.0

1. Основное содержание:
• Введение в стандарт, объяснение его эволюции и необходимости обновления.
• Упоминание о том, что стандарт был создан с участием глобального сообщества бизнес-анализа.

• Упор на сохранение шести областей знаний и 30 задач бизнес-анализа.
• Рекомендация использовать BABOK Guide для подготовки к сертификации.

Версия 2.0

1. Основное содержание:
• Введение в стандарт как основу профессионального бизнес-анализа.
• Упоминание о том, что стандарт был разработан в сотрудничестве с международным сообществом профессионалов.
• Основные изменения:
• Улучшение читаемости и упрощение языка.
• Выравнивание с BABOK Guide и соответствие стандартам ISO.
• Часть сведений расширена и перенесена в раздел Introducing the Business Analysis Standard.

• Упор на практическое применение задач и создание ценности.

Основные отличия:

1. Фокус:
• В версии 1.0 акцент сделан на эволюции стандарта и его роли в профессиональном сообществе.
• В версии 2.0 больше внимания уделено улучшению структуры, читаемости и практическому применению.
2. Структура:
• Часть сведений расширена и перенесена в раздел Introducing the Business Analysis Standard.
3. Язык и стиль:
• Версия 2.0 использует более упрощенный и современный язык, соответствующий стандартам ISO.

Сравнение раздела "Introducing the Business Analysis Standard" в версиях 1.0 и 2.0:

Версия 1.0

1. Название раздела: Раздел "Introducing the Business Analysis Standard" отсутствует как отдельный элемент.
2. Содержание:
• Введение в стандарт представлено в разделе "Preface".
• Основное внимание уделено эволюции стандарта, его роли как основы профессионального бизнес-анализа и соответствию принципам ISO.
• Упоминается, что стандарт был создан с участием глобального сообщества бизнес-анализа и включает проверенные практики.

Версия 2.0

1. Название раздела: "Introducing the Business Analysis Standard".
2. Содержание:
• Раздел выделен как отдельная глава.
• Описывается цель стандарта: служить основой для профессионального бизнес-анализа, предоставляя практическое руководство.
• Включены подразделы:
• "Defining the Standard" (Определение стандарта).
• "Contributions to the Standard" (Вклад в стандарт).
• "Why the Need for the Standard?" (Почему нужен стандарт?).
• Упоминается, что стандарт обновлен для улучшения читаемости, выравнивания с BABOK Guide и соответствия стандартам ISO.

Основные отличия:

1. Наличие раздела:
• В версии 1.0 раздел "Introducing the Business Analysis Standard" отсутствует как отдельный элемент.
• В версии 2.0 он выделен в отдельную главу с четкой структурой.
2. Фокус:
• В версии 1.0 введение сосредоточено на эволюции стандарта и его роли.
• В версии 2.0 добавлены подробности о целях, вкладе сообщества и необходимости стандарта.
3. Структура:
• Версия 2.0 включает подразделы, которые упрощают навигацию и восприятие информации.

Сравнение раздела "Understanding Business Analysis" в версиях 1.0 и 2.0:

Версия 1.0

1. Основное содержание:
• Определение бизнес-анализа: "Бизнес-анализ позволяет вносить изменения в предприятие, определяя потребности и предлагая решения, которые создают ценность для заинтересованных сторон".
• Основные концепции:
• Изменение (Change): Акт трансформации в ответ на потребность.
• Потребность (Need): Проблема или возможность, требующая решения.
• Решение (Solution): Способ удовлетворения одной или нескольких потребностей в определенном контексте.
• Ценность (Value): Значимость или полезность чего-либо для заинтересованных сторон.
• Заинтересованные стороны (Stakeholders): Группы или лица, связанные с изменением, потребностью или решением.
• Контекст (Context): Обстоятельства, влияющие на изменение.
• Использование модели BACCM™ (Business Analysis Core Concept Model™) для описания и улучшения бизнес-анализа.
• Примеры применения бизнес-анализа: поддержка стратегического принятия решений, трансформация организаций, улучшение бизнес-процессов и выравнивание результатов проектов с общей стратегией.

Версия 2.0

1. Основное содержание:
• Определение бизнес-анализа: "Практика, позволяющая вносить изменения в предприятие, определяя потребности и предлагая решения, которые создают ценность для заинтересованных сторон в заданном контексте".
• Основные концепции:
• Изменение (Change): Акт трансформации в ответ на потребность.
• Потребность (Need): Проблема или возможность, требующая решения.
• Решение (Solution): Способ удовлетворения одной или нескольких потребностей в определенном контексте.
• Ценность (Value): Значимость или полезность чего-либо для заинтересованных сторон.
• Заинтересованные стороны (Stakeholders): Группы или лица, связанные с изменением, потребностью или решением.
• Контекст (Context): Обстоятельства, влияющие на изменение.
• Расширенное использование модели BACCM™ как "модели мышления" и "организационной модели" для эффективного бизнес-анализа.
• Важность бизнес-анализа для понимания проблем, приоритизации потребностей и создания решений, ориентированных на ценность.
• Добавлены новые разделы, такие как "Outcomes and Value Creation" (Результаты и создание ценности), которые подчеркивают важность создания ценности на всех уровнях организации.

Основные отличия:

1. Фокус:
• В версии 1.0 акцент сделан на определении бизнес-анализа и введении модели BACCM™.
• В версии 2.0 больше внимания уделено созданию ценности и результатам, а также расширенному использованию модели BACCM™.
2. Структура:
• Версия 2.0 включает дополнительные разделы, такие как "Outcomes and Value Creation", которые отсутствуют в версии 1.0.
3. Язык и стиль:
• Версия 2.0 использует более структурированный и современный подход, включая четкие определения и примеры применения.

Сравнение раздела "Mindset for Effective Business Analysis" в версиях 1.0 и 2.0:

Версия 1.0

1. Основное содержание:
• Важность мышления: Установленные привычки и установки, которые человек привносит в различные ситуации, определяют, как он думает и действует.
• Принципы для эффективного мышления:
• Видеть целостную картину.
• Думать как клиент.
• Анализировать, чтобы определить, что ценно.
• Использовать примеры для понимания реальности.
• Понимать, что возможно.
• Стимулировать сотрудничество и непрерывное улучшение.
• Избегать потерь.
• Гибкость и адаптивность как ключевые элементы мышления.
• Применение принципов из Agile Extension к BABOK® Guide.

Версия 2.0

1. Основное содержание:
• Важность мышления: Мышление — это ментальная структура, которая направляет принятие решений, поведение и динамику команды.
• Принципы для эффективного мышления:
• Видеть целостную картину.
• Думать как клиент.
• Анализировать, чтобы определить, что ценно.
• Использовать примеры для понимания реальности.
• Понимать, что возможно.
• Стимулировать сотрудничество и непрерывное улучшение.
• Избегать потерь.
• Расширенные ценности:
• Уважение.
• Мужество.
• Этика.
• Любопытство.
• Максимизация ценности.
• Гибкость и адаптивность как ключевые элементы мышления.
• Упор на использование модели BACCM™ для создания ценности и улучшения процессов.

Основные отличия:

1. Фокус:
• В версии 1.0 акцент сделан на базовых принципах мышления и их применении.
• В версии 2.0 добавлены ценности, такие как уважение, этика и любопытство, а также упор на использование модели BACCM™.
2. Структура:
• Версия 2.0 включает более детализированное описание принципов и их применения.
3. Язык и стиль:
• Версия 2.0 использует более современный и структурированный подход, включая четкие определения и примеры.

Сравнение разделов "Performing Business Analysis" (версия 1.0) и "Implementing Business Analysis" (версия 2.0):

Версия 1.0: "Performing Business Analysis"

1. Основное содержание:
• Кто выполняет бизнес-анализ:
• Бизнес-анализ выполняется профессионалами в различных ролях, включая бизнес-аналитиков, архитекторов, менеджеров продуктов, аналитиков данных и других.
• Подходы к работе:
• Используются предсказуемые, адаптивные и гибридные подходы.
• Важность выбора подхода, соответствующего контексту.
• Создание ценности:
• Фокус на понимании стратегии предприятия, выявлении проблем и возможностей, создании решений, ориентированных на ценность.
• Организационные аспекты:
• Учет таких факторов, как устойчивость, инклюзия, разнообразие и справедливость.
• Управление доставкой:
• Организация услуг бизнес-анализа через Центры передового опыта (CoE), сообщества практики (CoP) или распределенные команды.

Версия 2.0: "Implementing Business Analysis"

1. Основное содержание:
• Организация услуг бизнес-анализа:
• Включает Центры передового опыта (CoE), сообщества практики (CoP), аутсорсинг (BAaS) и распределенные команды.
• Управление доставкой:
• Создание стандартов, включающих процессы, процедуры, шаблоны и руководства.
• Важность совместного использования знаний, инструментов и опыта для повышения качества работы.
• Применение задач бизнес-анализа:
• 30 задач, описанных в BABOK Guide, служат основой для эффективного бизнес-анализа.
• Задачи могут выполняться одновременно, а некоторые из них генерируют результаты, необходимые для последующих задач.
• Фокус на стратегическом выравнивании:
• Поддержка стратегического выравнивания через стандарты и практики.

Основные отличия:

1. Фокус:
• В версии 1.0 акцент сделан на выполнении задач бизнес-анализа и создании ценности.
• В версии 2.0 больше внимания уделено внедрению стандартов и управлению услугами бизнес-анализа.
2. Организационные аспекты:
• В версии 1.0 обсуждаются такие темы, как устойчивость и инклюзия.
• В версии 2.0 акцент сделан на стандартизации и стратегическом выравнивании.
3. Структура:
• Версия 2.0 включает более детализированное описание задач и их применения.

Сравнение разделов "Tasks and Knowledge Areas" (версия 1.0) и "Applying Business Analysis Tasks" (версия 2.0):

Версия 1.0: "Tasks and Knowledge Areas"

1. Основное содержание:
• Шесть областей знаний:
• Планирование и мониторинг бизнес-анализа.
• Выявление и сотрудничество.
• Управление жизненным циклом требований и дизайнов.
• Стратегический анализ.
• Анализ требований и определение дизайна.
• Оценка решений.
• 30 задач бизнес-анализа:
• Задачи представлены в виде "карточек задач", каждая из которых включает:
• Цель задачи.
• Ценность.
• Решение (результат или выход).
• Заинтересованные стороны.
• Описание изменений.
• Часто используемые техники.
• Ссылки на сертификации IIBA.
• Гибкость выполнения задач:
• Задачи могут выполняться в любом порядке, итеративно или одновременно, в зависимости от контекста.
• Ссылки на BABOK Guide:
• Для детального изучения задач рекомендуется обращаться к BABOK Guide.

Версия 2.0: "Applying Business Analysis Tasks"

1. Основное содержание:
• Фокус на задачах:
• 30 задач бизнес-анализа описаны с акцентом на практическое применение.
• Задачи представлены в формате "карточек задач", включающих:
• Цель задачи.
• Ценность.
• Решение (результат или выход).
• Часто используемые техники.
• Отсутствие областей знаний:
• В отличие от версии 1.0, области знаний не включены в стандарт. Для их изучения рекомендуется обращаться к BABOK Guide.
• Гибкость выполнения задач:
• Задачи могут выполняться в любом порядке, итеративно или одновременно, в зависимости от контекста.
• Практическая направленность:
• Стандарт предоставляет пошаговые инструкции для выполнения задач, что делает его более прикладным.

Сравнение раздела "Summary" в версиях 1.0 и 2.0 документа "The Business Analysis Standard":

Версия 1.0: "Summary"

1. Основное содержание:
• Документ предоставляет краткое и ценное введение в дисциплину бизнес-анализа.
• Определяет основные термины и демонстрирует широкий спектр инициатив, которые выигрывают от качественного бизнес-анализа.
• Подчеркивает равную важность требований и дизайнов.
• Вводит модель BACCM™ как основу для эффективного бизнес-анализа.
• Уделяет внимание важности мышления и его целенаправленного применения.
• Определяет ключевые компетенции и техники.
• Включает 30 задач бизнес-анализа в рамках шести областей знаний.
• Приводит примеры применения задач в различных бизнес-контекстах.

Версия 2.0: "Summary"

1. Основное содержание:
• Документ предоставляет упрощенный, всеобъемлющий и инклюзивный взгляд на основные концепции эффективного бизнес-анализа.
• Подчеркивает важность мышления как предпосылки для качественного бизнес-анализа.
• Вводит 30 задач бизнес-анализа, но без привязки к областям знаний.
• Приводит примеры применения задач в различных бизнес-контекстах.
• Подчеркивает роль BACCM™ как основы для анализа.
• Уделяет внимание практическому применению задач и их гибкости.
• Документ служит основой для будущего развития стандартов и ресурсов бизнес-анализа.

Основные отличия:

1. Фокус:
• В версии 1.0 акцент сделан на введении областей знаний и задач.
• В версии 2.0 больше внимания уделено упрощению и практическому применению задач.
2. Структура:
• Версия 1.0 включает шесть областей знаний, в то время как версия 2.0 исключает их, сосредотачиваясь на задачах.
3. Язык и стиль:
• Версия 2.0 использует более современный и инклюзивный подход, делая акцент на гибкости и применимости задач.

Сравнение разделов "Glossary" и "Contributors" в версиях 1.0 и 2.0 документа "The Business Analysis Standard":

Версия 1.0

1. Glossary:
• Раздел "Glossary and Key Terms" присутствует.
• Включает ключевые термины, такие как "Adaptive Planning", "Business Analysis as a Service (BAaS)", "Risk", и другие.
• Содержит ссылки на BABOK Guide для более подробного изучения терминов.
2. Contributors:
• Раздел "Contributors" присутствует.
• Включает список участников разработки стандарта, таких как Jas Phul, Catherine Elder, Patrick J. McNeill и другие.
• Упоминаются участники воркшопов и корпоративные члены, внесшие вклад в разработку.

Версия 2.0

1. Glossary:
• Раздел "Glossary and Key Terms" упоминается, но перенесен в KnowledgeHub.
• В документе указано, что для изучения терминов следует обращаться к KnowledgeHub Glossary.
2. Contributors:
• Раздел "Contributors" отсутствует в документе.
• Упоминается, что информация о разработчиках и участниках доступна в KnowledgeHub.

Основные отличия:

1. Glossary:
• В версии 1.0 раздел "Glossary and Key Terms" включен в документ.
• В версии 2.0 Glossary перенесен в KnowledgeHub.
2. Contributors:
• В версии 1.0 раздел "Contributors" присутствует с подробным списком участников.
• В версии 2.0 информация о разработчиках и участниках доступна только в KnowledgeHub.

Ссылка на knoledgehub - https://www.iiba.org/knowledgehub/glossary/

1. Общие положения и нормативная база

1. Переход к единому документу (ИП)
• Ранее: существовали два документа (предварительное и основное технико-экономическое обоснование, ТЭО).
• Теперь: вместо двухэтапного процесса (ПТЭО + ТЭО) используется одноэтапная схема — составляется инвестиционное предложение (ИП).
2. Государственный инвестиционный проект (ГИП)
• Согласно законодательству, ГИП — это комплекс мероприятий, направленных на достижение стратегических целей государства путём реализации бюджетных инвестиций и/или проектов ГЧП.
• В ИТ-сфере ГИП включает создание и развитие объектов информатизации электронного правительства (ИС, порталы, сети, серверные комплексы и т.д.).
3. Правовые акты
• Закон «Об информатизации» (определяет понятия информационных систем, объектов ИКТ, регламентирует вопросы архитектуры госорганов).
• Бюджетный кодекс (регламентирует порядок и требования к госинвестиционным проектам).
• Постановление Правительства РК об утверждении Правил разработки, корректировки и проведения экспертиз инвестиционных предложений (там указана структура ИП, порядок согласования).
• Приказы Министерства цифрового развития (МЦРИАП) о методике расчёта затрат на создание/сопровождение объектов информатизации, требованиях к архитектуре электронного правительства и др.

2. Инвестиционное предложение (ИП): понятие и структура

1. Назначение ИП
• Обосновать необходимость создания или развития объекта информатизации (проблематика, цели, масштаб).
• Показать варианты (не менее двух) реализации проекта и выбрать оптимальный.
• Подтвердить стоимость и смету (по методике расчёта или на основе коммерческих предложений).
• Сформировать техническую часть (архитектуру, нагрузку, оборудование и т.д.).
2. Состав ИП (пакет документов)
1. Информационный лист (подробное описание сути проекта, обоснование, маркетинговый анализ и технический раздел).
2. Отраслевое заключение (госорган сам подтверждает, что проект важен и в интересах отрасли).
3. Расчёты по финансированию (бюджетные инвестиции, ГЧП, сервисная модель и т.д.).
4. Обоснование стоимости (согласно методике МЦРИАП + при необходимости коммерческие предложения).
5. Техническое задание (ТЗ) — обязательно, если нет ранее утверждённого ТЗ на данный объект информатизации.
3. Содержание информационного листа
• Маркетинговый (отраслевой) анализ:
• Описание проблематики и текущей ситуации,
• Нормативно-правовые основания (закон, кодекс, программа),
• Оценка спроса или социальной необходимости,
• Целевая аудитория (пользователи, выгоды).
• Социально-экологический анализ (при необходимости — влияние на экологию, социальные эффекты).
• Технико-технологические решения:
• Архитектура (логическая, технологическая),
• Расчёт вычислительных ресурсов, объёмов данных, нагрузки,
• Схема телекоммуникаций и требования по инфобезопасности,
• График реализации и план работ,
• Оценка интеграции с другими системами.
• Альтернативные варианты (не менее двух сценариев по технологиям, ПО, оборудованию).

3. Порядок подготовки и согласования ИП

1. Инициирование
• Основание: архитектура госоргана (перечень необходимых проектов), поручения правительства/президента, либо иные документы.
• Госорган формирует ИП (при необходимости привлекает консультантов).
2. Внутренние согласования
• В госоргане: политическая воля (министерство, вице-министр), отраслевое заключение.
• Подготовка пакета документов.
3. Экспертиза
• «Зерде» и МЦРИАП (уполномоченный орган по информатизации) проверяют целесообразность, соответствие единым требованиям ИКТ и архитектуре.
• ГТС (комитет информационной безопасности) даёт заключение по части ИБ (включая требования по Шлюзу, сетям, стандартам ИБ).
• При необходимости - Миннацэкономики (экономическая экспертиза, бюджетная эффективность).
4. Выход на бюджетную комиссию
• При одобрении экспертиз госорган подаёт заявку на выделение бюджетных средств.
• Бюджетная комиссия утверждает финансирование.
5. Итог
• После положительного решения выделяются средства, и госорган может проводить тендеры/закупки и стартовать проект.

4. Команда и ключевые роли

1. Госорган
• Формально разработчик ИП — сам государственный орган;
• Внутри госоргана: проектная группа (аналитики, юристы, ИБ-специалисты, финансисты).
2. Поддержка архитекторов
• Холдинг «Зерде» часто разрабатывает доменные архитектуры, где указываются будущие ИТ-проекты.
• Архитекторы могут помочь описать логическую и техническую структуру решений.
3. Менеджер проекта
• Координирует сбор данных, формирование разделов ИП, взаимодействие с экспертами и госорганом.
4. Аналитик
• Составляет основную текстовую часть ИП: маркетинговый анализ, бизнес-функции, требования, расчёты (или компонуя уже готовые цифры).
5. Архитектор (ИТ-специалист)
• Рисует и обосновывает архитектуру (диаграммы, схемы нагрузки, компоненты системы, схемы интеграции).
6. Финансист
• Рассчитывает стоимость (методика, коммерческие предложения), готовит разделы по видам финансирования.

5. Содержание и особенности ключевых разделов

5.1. Маркетинговый/отраслевой анализ

• Описывает:
• Проблемы в текущей деятельности,
• Законодательные основания (законы, кодексы, приказы),
• Существующие ИС и их недостатки,
• Статистику, отчётность, масштаб (число пользователей, какие функции не автоматизированы).
• Цель: показать, почему нужен проект или развитие системы (социально-экономическое обоснование).

5.2. Расчёт стоимости (методика МЦРИАП)

• Методика основана на количестве вариантов использования (Use Cases), объектах данных, интеграциях и т.д.
• На практике методика может давать завышенные суммы, поэтому принято прикладывать ещё 2–3 коммерческих предложения с рынка (для обоснования или снижения сметы).
• Итогом становится смета на:
• Инвестиционные затраты (разработка, закупки, внедрение, тестирование ИБ),
• Эксплуатационные (операционные) затраты (аренда облака, сопровождение, техническая поддержка и т.д.).

5.3. Архитектура и технические решения

1. Архитектурные схемы
• Логическая архитектура: слои (презентационный, бизнес-логика, данные, интеграции).
• Технологическая архитектура: где (в каком центре обработки данных), какие сервера, сеть, ПО.
• Схема телекоммуникаций: как соединяется внутренний и внешний контур, шлюзы и т.п.
2. Расчёт нагрузки
• Кол-во пользователей, транзакций, пиковая нагрузка (транзакции/минуту), объёмы хранения, ежегодный прирост данных.
• На базе этих цифр определяются требования к мощности (число ядер, оперативная память, объём хранения и т.д.).
3. Интеграции
• Нужно указать, с какими существующими ИС будет обмен данными, описать протоколы/механизмы взаимодействия.
4. Информационная безопасность
• Указать класс (по классификатору ИС), перечень стандартов ИБ, необходимость прохождения испытаний/аттестаций.
• Обычно это согласуется с комитетом (ГТС) на этапе экспертизы.

5.4. Альтернативные варианты реализации

• По правилам требуется сравнить не менее двух вариантов:
• Например, пр proprietary (лицензионное) vs. open source (свободное ПО),
• Закуп физического оборудования vs. размещение в облаке,
• Разные вендоры серверов или СУБД.
• В каждом варианте: примерная архитектура, смета, плюсы/минусы.
• Выбор оптимального обосновывается: цена, соответствие требованиям госоргана, наличие скидок и т.д.

6. Создание vs. развитие vs. сопровождение

1. Создание
• Полностью новая система или объект информатизации (нет ранее утверждённого ТЗ).
• ИП включает обязательное техническое задание (подробно описывает функции, архитектуру, интеграции).
2. Развитие
• Расширение функционала, крупное обновление, замена устаревшего оборудования, переход на другую платформу и т.п.
• Тоже оформляется новым ИП (или корректировкой предыдущего, если предусмотрено в рамках того же проекта).
• По сути, снова проходит экспертизу и утверждение финансирования.
3. Сопровождение
• Ежегодные затраты на поддержание (хостинг, техническая поддержка).
• Формально на «чистое» сопровождение без развития бюджет не выделяют (требуется либо закладывать в ИП изначально на 3–5 и более лет, либо оформлять развитие).
• Если деньги на сопровождение истекли — могут либо продлить с помощью нового ИП (развития), либо переводить систему на «утрату» (в реальности чаще ищут обходные пути).

7. Практические рекомендации и типичные сложности

1. Политическая воля
• Критически важно, чтобы министр/вице-министр поддерживал проект, иначе ИП может «зависнуть».
2. Корректность и полнота
• При несоответствии формальным требованиям (разделы маркетинга, альтернативы, схемы, сметы) ИП возвращают на доработку.
3. Методика расчёта
• Часто даёт завышение в 2–3 раза, поэтому дополнительно используют коммерческие предложения.
• Госорган «играет» цифрами, чтобы обосновать нужный бюджет и показать «оптимальное» решение.
4. Экспертиза и сроки
• Полный цикл (от написания ИП до бюджетной комиссии) может занять до года.
• Если есть «административный ресурс», могут пройти быстрее, но чаще (особенно при уточнении архитектуры) процесс затягивается.
5. Дублирование и обновление ТЗ
• По новому законодательству ТЗ должно быть приложено к ИП. Если это «развитие», то пишется новое ТЗ (полное или дополнение).
• Содержательно ТЗ во многом пересекается с разделами самой архитектуры.

8. Выводы

• Инвестпредложение (ИП) – ключевой документ для получения бюджетных средств на ИТ-проекты госорганов.
• Структура ИП охватывает и бизнес-обоснование (маркетинг, ретроспектива) и техническую часть (архитектура, нагрузка, интеграции).
• Успешность согласования зависит от:
1. Политической воли и заинтересованности госоргана.
2. Корректного оформления и соблюдения всех регламентных требований (включая альтернативные варианты).
3. Точной (или хотя бы разумной) оценки стоимости (методика + коммерческие предложения).
• Проекты госорганов должны быть увязаны с архитектурой госоргана и принципами развития электронного правительства (минимизировать «собственные» серверные мощности, по возможности использовать облако и свободное ПО и пр.).

Краткая итоговая схема (самое главное):

1. Анализ проблематики и целей → 2. Маркетинговый и технико-технологический раздел (архитектура, расчёты нагрузки, ИБ) → 3. Методика расчёта стоимости + коммерческие предложения → 4. Два альтернативных варианта → 5. Выбор оптимального → 6. Оформление и подача ИП → 7. Экспертизы «Зерде» / МЦРИАП / Миннацэкономики → 8. Бюджетная комиссия → 9. Выделение финансирования и старт проекта.

Два пути — и оба связаны с верой

В известном смысле существуют два базовых маршрута. Первый — харизматический: появляется группа фанатиков, которые внезапно включают турбо-режим и говорят, что у них есть «истина в последней инстанции». Эта «истина» бывает религиозной (ислам, например) или вполне себе квазирелигиозной (будь то коммунизм, национализм, либерализм — или всё сразу). «Либо вы с нами, либо умираете в страшных муках». Второй путь — консервативный. Тут всё спокойнее: поколениями складывается государственность, из неё выплетают миф, подмешивают немного сакральности — и вот вам «великая цивилизация» в окружении «варваров». Фараоны, Рим, Китай, всё как в учебнике. Сперва просто приходят к власти, потом носят на голове красивую корону, а дальше начинается культ императора, «поднебесная», «мандат неба» и Pax Romana.

Харизматический порыв: огонь в глазах и завоевательные походы

Примеры:

• Ранний арабский халифат (VII–VIII века): у всех в памяти. Прямо моментально на конях (или пешком) прошли полмира, объяснили, что пророк Мухаммад принёс последнюю версию Откровения. Все наши — халифат процветает, все чужие — подчиняйтесь или будете подчиняться.
• Франция времён Наполеона: фанатичная вера в «экспорт революции». Была одна идея: «мы — в авангарде, несём свободу». Ударили по соседям, приобщили к себе пол-Европы, да и сами поверили в свой культ.
• Ранняя большевистская Россия: гремят рельсы, красногвардейцы из пулемётов стреляют, а в голове — «Мировая революция». Либо вы с нами делаете коммунизм, либо мы вас убедим всенепременно — хоть через террор, хоть через пропаганду.
• Нацистская Германия: параноидальная вера в расовую теорию и святого фюрера как главного «спасителя» Европы. И ведь почти спасли — только немножко не успели.
• США (эпохи Войны за независимость и последующих десятилетий): фанатичный (в хорошем смысле) подъём под лозунгами свободы и равенства. «Мы — новаторское общество», «кто не с нами — тот монархический ретроград». Затем — не менее яркое убеждение в «избранничестве» и «предназначении» (Manifest Destiny), оправдывающее экспансию на запад и формирование новой республики «с идеалами для всего человечества».

Распространение идей тоже закономерно: создаётся ядро «ультра-верующих», которое либо вербует, либо расстреливает противников. В результате — быстрое «расширение пространства», захват власти и появление нового типа государства.

Консервативный путь: тихое обрастание ритуалами

Здесь особых вспышек «фанатизма» нет (по крайней мере, на поверхности). Скажем, изначально существовала вполне себе работоспособная система институтов. Раз — и в результате столетних усилий, кстати, почти незаметно, эти институты становятся священными. Древний Египет: был нормальный правитель, стал «бог на Земле». Рим: сначала республика, затем — давайте сделаем культ императора. Вот вам, граждане, Pax Romana, все учтиво кланяются бронзовой статуе Цезаря или Августа. Имперский Китай: «поднебесная», и императору «мандат Неба» при рождении, отобрать нельзя, а если и можно, то очень трудно. Британская монархия в XIX–XX веках: у нас же самый «настоящий» царствующий дом, все традиции соблюдены, флаги, гвардейцы, корги у ног Елизаветы II — не придерёшься. Не забываем и титул «Императора Индии», между прочим.

Кстати, и США, добившись независимости, довольно быстро обзавелись конституционным культом. Со временем «отцы-основатели» перешли в статус почти библейских фигур. Той самой искры революционной харизмы уже не было, зато появилось почтение к «вечным» принципам — Биллу о правах, к «старейшей конституции в мире» и т. п. Тоже крайне консервативная часть американской идентичности.

Трансформация: от буйства страстей к «свитеру с оленями»

Интереснейшая закономерность: харизматические государства нередко превращаются в консервативные. Возьмём Османскую империю: сначала все бегут в завоевательные походы, потом — внушительный бюрократический аппарат, гаремы, дворцовые интриги. Где тот огонь? Он погас, оставив после себя традицию. Советский Союз: начинал с ленинско-троцкистского взрыва («мировая революция»), а закончил застоем и очередями за колбасой. Значит, стал консервативным государством с партноменклатурой, номенклатурными дачами и культом «нашей необъятной родины» вместо мирового пожара. Наполеоновская Франция: Реставрация, Бурбоны, потом новый Наполеон (только менее харизматичный), и снова тихий контроль, больше похожий на консервативный режим. США тоже прошли через это: от воодушевлённой борьбы «за свободу» в XVIII веке — к постепенному формированию крайне устойчивой системы с мощными традициями и бюрократией к концу XIX века.

А у нас в Казахстане?..

После развала Союза кое-кто надеется вылепить в Казахстане особую «национальную идею». Причём есть два теоретических «сценария»:

1. Харизматический: возникновение «фанатиков» — условно говоря, националистов или религиозных радикалов. Они захватывают власть, насаждают идеологию, и весь Казахстан бегом марширует под новые знамена. Риск большой, но эффект шокирующий.
2. Консервативный: плавное построение исключительного по эффективности общества. Сорок–пятьдесят лет, а может, и сто. После чего мы имеем традицию, сакральные символы, «казахскую вечность» и т. п. Любой школьник в новой столице (где-нибудь под Кызылордой) скажет: «наша цивилизация вечна!».

Чего хотят «элиты», когда говорят «давайте придумаем национальную идею»?

Сюрприз: обычно никакой новой идеи никто не хочет. Ибо настоящая идея — это перемены, риск потерять активы и должности. А нужно же «стабильность» и «законсервированное настоящее». То есть, как всегда, создаётся такая себе «легитимизирующая платформа», которая объяснит массам: «почему мы здесь сидим, нас не сдвинуть, да и не надо». Желающим поморщиться можно предложить сказку про «древние корни» или наоборот — «великую модернизацию». Людям не так важно, лишь бы выглядело солидно. Рецепт простой: объявляем всё это «единственным путём» и «подлинно казахстанской уникальностью». Кто не согласен — в чёрный список. А кто согласен — добро пожаловать в ряды «патриотов». Конечно, народ мог бы сказать: «не нужна нам ваша идея, дайте пожить спокойно», но кто нас спрашивает?

Итак, имеем классику: либо громкий фанатичный рывок — но тогда будет сильно трясти, и элитам придётся идти ва-банк, либо мучительно неторопливое созидание, к которому элиты, в общем-то, не очень готовы. Пока на казахстанских просторах нет ни революционной искры, ни чёткой линии на супермодернизацию — значит, скорее всего, останемся на прежнем уровне «и так сойдёт». Тем более, какую-никакую легитимизирующую тему уже пытаются подыскать. А это, согласитесь, лучше, чем ничего.