Файл: Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 18.01.2024

Просмотров: 822

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Данные каждой компании хранятся в единой информационной системе холдинга.
Преимущества данного решения – помимо всех преимуществ IaaS и PaaS предоставляет единую информационную систему холдинга. Каждая компания является частью холдинга. Информация по справочникам, номенклатуре, плану счетов унифицирована имеется возможность формирования консолидированных (суммированных по статьям) отчетов. Возможность интерактивного воздействия в процесс управления (авторизация и т п) со стороны руководства портфеля или холдинга. Данная модель подходит для финального этапа централизации ИТ. Как и для предыдущей модели, крайне важно ответить на два вопроса: первый – в чем цель и конечный результат, и второй – иметь четкую диаграмму всех бизнес процессов организации в целом, и компаний в частности.
Для реализации данного плана, необходима заинтересованность руководства холдинга, поддержка руководства на местах, и тесная интеграция специалистов бизнеса и ИТ, хорошо разбирающихся в деталях процессов, происходящих в компании. Переход на унифицированную платформу, может потребовать значительные финансовые инвестиции и временные рамки, как для анализа, так и для поэтапного внедрения. Результаты интеграции будут видны только в долгосрочной перспективе. Данный этап характерен высоким риском в процессе интеграции. Кроме этого, процесс вывода компании из состава организации или холдинга может быть так же достаточно сложным и болезненным.
Процесс доработки функционала для каждой компании, общий для всех компаний.
Проблемы выбора ИТ-решения для Бизнеса
Информационные Системы бизнеса находятся на стыке взаимодействия бизнеса и ИТ. В этом кроется основная сложность, и является источником возникновения конфликтов, недопонимания и недовольства. Остро встают вопросы и проблемы, освещенные в данной книге ранее, в главе
«Концепция построения Архитектуры Предприятия». При этом не имеет значения масштаб
организации (небольшая автономная компания или сложный холдинг со множеством направлений бизнеса), фаза становления (начало ведения бизнеса или долгое и устойчивое пребывания на рынке) или уровень компетенции сотрудников (молодой специалист, только закончивший институт или «матерый» сотрудник с огромным стажем по своей специальности) проблемы у всех одни и те же вопрос только насколько у кого «болит».
Так при выборе Информационной Системы сугубо технического направления (защита периметра, системы Антивирусной защиты и т п) или общего назначения (Сервис предоставления файлов в совместное использование, системы почтовых сообщений и т п), выбор решения фактически полностью зависит от технических специалистов в области ИТ или
Информационной Безопасности. Они говорят на одном «языке»; разбираются в особенностях решений, требованиям предъявляемых к системам и т п. Взаимодействие с бизнесом минимальное. Бизнес требования со стороны бизнеса могут быть сформулированы одним предложением: «… чтобы можно было посылать и принимать почту…». Как видно из рисунка,
«вершина айсберга» – бизнес требования видны сотрудникам организации лишь часть общих требований к системе.
Вся суть коммуникации между бизнесом и ИТ сводится на пример к запросу, как слышит бизнес: «… дайте деньги на память…», что на языке ИТ сотрудников значит: «… Выделите финансирование на закупку модулей оперативной памяти для серверов…».
При выборе Информационной Системы для бизнеса, со стороны ИТ требования к системе остаются фактически таким же, как и прежде, но «айсберг» переворачивается и центр смещается к требованиям бизнеса. Хорошо, если бизнес может сформулировать требования, как в общем, так и с учетом специфики конкретной организации, что позволит ИТ разработать или купить решение, удовлетворяющее требованиям бизнеса и вписывающиеся в общую ИТ Архитектуру.
На практике, часто руководство бизнеса самостоятельно принимает решение без обсуждения с представителями ИТ, что в конечном этапе приводит к «зоопарку» решений, не эффективному использованию систем и высокой стоимости сопровождения. Или же требования бизнеса сформулированы очень обширно «… нужна система для видения бухгалтерского учета…», а вы
ИТ должны найти и выбрать.


Даже если представители бизнеса прекрасно понимают, что им нужно, умеют правильно сформулировать свои требования, ясно видят перспективы роста бизнеса и прочие нюансы, важные в процессе выбора решения – это всего лишь решает внутреннюю проблему.
Необходимо обратить внимание на внешнюю сторону проблемы.
Ситуация выбора ИТ-решения усугубляется тем фактором, что на современном рынке помимо достаточно широкого выбора самих систем появились различные варианты приобретения и внедрения этих систем. Одну и ту же систему можно заказать «под ключ» у компании производителя или же приобрести у производителя и самостоятельно внедрить силами сотрудников ИТ подразделения предприятия) или силами интегратора.
Следующим фактором, который влияет на выбор ИС, а также способа ее приобретения, являются критерии, по которым принимается решение в пользу той или иной системы.
В большинстве случаев при выборе ИС ИТ-директора руководствуются экономическими эффектами, однако даже в этом случае ситуация является непростой. Так, помимо затрат на реализацию проекта по внедрению, необходимо учитывать затраты на совокупное владение системой, которые включают затраты на поддержку и развитие системы, обучение персонала, обновление оборудования, косвенные затраты (простои, отказы ИС и др.) и риски. При этом статистика говорит о том, что при сроке эксплуатации ИС в 3 года стоимость владения системой сравнивается (а очень часто и превышает) с затратами на внедрение ИС. Помимо экономических показателей, критериями при выборе ИС могут являться дополнительные факторы: скорость введения системы в эксплуатацию, наличие дополнительной функциональности в платформе, риски при реализации проекта и др. Таким образом, даже с учетом только экономических факторов, задача выбора ИС является многокритериальной. Наличие нескольких критериев усугубляется тем, что необходимо определить приоритеты или предпочтения каждого из критериев, чтобы решение о выборе ИС максимально соответствовало предпочтениям
ИТ-директора и стратегическим целям предприятия.
Нельзя также не учитывать тот факт, что и оценка эффективности, и рассмотрение критериев производятся не одним человеком. Зачастую решение о выборе информационной системы
формируется у ИТ-руководителя на основании мнений одного, а чаще нескольких экспертов.
При этом каждый эксперт имеет свою точку зрения на проблему, которая чаще всего отличается от видения этой же проблемы другим экспертом. Мнения могут отличаться как в оценках эффекта от внедрения ИС (затраты и положительные эффекты), так и приоритетности критериев.
Таким образом, многокритериальную задачу выбора ИС приходится решать на основании экспертных мнений нескольких лиц, что еще более усложняет выбор ИС.
С другой стороны, выбор бизнес решений производится зачастую узким кругом руководителей без привлечения ИТ, что часто приводит к выбору по принципу: «… давайте возьмём как у той компании, если у них работает, то и у нас тоже будет…», или «… давайте возьмём самое дорогое решение – оно, наверное, самое лучшее…», или что еще хуже преследуя какие-то свои скрытые цели.
Рекомендации по выбору Информационной Системы Управления
Ни одна из методик оценки эффективности Информационной Системы, ни совместное использование нескольких методик не позволяет однозначно решить задачу выбора той или иной информационной системы. Сейчас на рынке представлено огромное множество решений, реализующих одни и те же бизнес-функции. Как правило, ИТ-проект на предприятии является комплексным и предполагает реализацию нескольких направлений и бизнес-функций.
Предлагаемые ИТ-решения также обладают достаточной гибкостью благодаря модульной архитектуре. В результате ИТ-директор сталкивается с необходимостью решить задачу, какие бизнес-функции ему необходимо реализовать сейчас, какие заложить на реализацию в будущем, а от каких необходимо и вовсе отказаться. То есть важно расставить приоритеты в функциональности ИС и запланировать ее развитие в будущем. В таком случае мы получаем целый набор вариантов ИТ-решений, из которого необходимо выбрать наиболее оптимальный как с точки зрения текущей функциональности, так и с точки зрения стратегического развития
ИТ-комплекса предприятия в целом и оптимальности финансовых затрат.
Критерии выбора ИТ решения
В качестве основных критериев выбора решения, можно определить следующие:
Какие цели?
•Какие процессы необходимо контролировать?
•Размер организации: (Small Business, Medium Business, Large Business)
•Заявленные возможности продукта или решения.
•Удовлетворяют ли заявленные возможности требованиям бизнеса?
•Техническая Архитектура:
°Архитектура решения: (client-server, Client-Application Server-Database Server)
°Серверная платформа: (Cloud based, Windows, Linux, Others)
°Варианты установки: (Cloud based или On-premises)
°Поддержка виртуализации: (Physical only, Hyper-V, VMware, Others)
°Поддерживаемые базы данных: (Microsoft SQL, MySQL, Internal DB)
На стороне клиента:
°Поддерживаемые устройства на клиенте: (Windows, Linux, Android, Mac OS, iPhone/iPad,
Web-based)
°Поддерживаемые языки интерфейса: (Single English, Multi-Languages, Customer)
Архитектура отказоустойчивости и доступности
•Архитектура восстановления и архивирования
•Возможности масштабирование решения
•Как данное решение вписывается в общую ИТ архитектуру.
•«Купить или сделать?» В зависимости от способа приобретения ИС показатели эффективности, в первую очередь финансовые, будут отличаться. К тому же каждый раз набор вариантов дополняет самостоятельная разработка ИС, которую также необходимо оценивать.
Оценка производителей и поставщиков решений (Рейтинг, Наличие локального партнера
(продажа / поддержка)
Модель внедрения:


°Стоимость: (Free (Open-Source), One-time payment, Monthly payment, Annual subscription,
Perpetual)
°Лицензирование: (Per servers, Per hosts, Per operators/agents, Per modules, Per users, Per
CPU/core, Per modules)
°Варианты подписки и версий
Модель сопровождения: (Technical support, Update support)
°Стоимость: (Free, Annual fee, Basic Technical support, Local support, Remote support)
°Лицензирование
°Возможности по обновлению продукта: (Update patches, Upgrade packs, Re-installation)
Возможности интеграции: с имеющимися решениями, с потенциально возможными решениями
В качестве общих рекомендаций по выбору ИТ решения для бизнеса я бы рекомендовал следующие варианты выбора в зависимости от имеющихся условий. Если бизнес не имеет четкого представления, какие требования предъявляются к системе, высокий уровень неопределённости в следствии объективных (направление деятельности новое для бизнеса, условия рынка и т п) или субъективных причин (низкий профессиональный уровень сотрудников, слабая или не определённая административная организация и т п), то возможны следующие варианты:
•Организация покупает недорогое, быстро внедряемое решение с набором базового функционала, для использования в течении года или двух. Цель – сформировать рабочие бизнес процессы, обучение персонала.
•Организация пытается разработать решение собственными силами. При том ИТ внедряет новый функционал по требованию со стороны бизнеса. Данный подход может занять больше времени для достижения тех же целей, что и в предыдущем варианте, но имеет ряд своих преимуществ, а именно – бизнес и ИТ получают более глубокое понимание бизнес процессов, система относительно проста так как имеет в своем наборе только необходимый функционал.
Дальнейшее развитие может происходить по двум направлениям – система дорабатывается и становится основным решением для организации, или же на базе решения формируется
«техническое задание» для выбора решения уровня предприятия.
•Организация выбирает имеющееся на рынке готовое решение с расширенным набором функций. Данное решение является основным для бизнеса и на его базе сотрудники постепенно осваивают бизнес процессы.
1   ...   15   16   17   18   19   20   21   22   ...   44

Этапы выбора ИТ решения
Можно определить следующий порядок действий по ИТ проекту.
На первом этапе:
•Сбор требований со стороны бизнеса – инициатора проекта (бизнес требования)
•Добавление технических требований со стороны департамента Безопасности
•Добавление технических требований со стороны ИТ департамента
На втором этапе:
•Поиск решений, без ограничений по стоимости, архитектуре и т п.
•Сбор заявленных возможностей решения
На третьем этапе:
•Анализ решений (со стороны бизнеса) на соответствие бизнес требованиям
•Анализ решений (со стороны ИТ департамента) на соответствие требованиям, архитектуре и т п
•Формирование «короткого» списка решений удовлетворяющих всем требованиям. При необходимости проводится обращение к департаменту Снабжения для получения предложений
На четвертом этапе:
•Детальный анализ решения, выбор архитектуры, производителя, определение бюджета и т п
•Принятие решения по бюджету, срокам (со стороны бизнеса)
•Формирование технического задания для проведения тендера
•Формирование плана внедрения (частичное, полное и т п)
•Выбор «короткого» списка победителей

•Уточнение последних изменений и дополнений
•Финальный тендер (по необходимости) для «короткого» списка компаний
На пятом этапе:
•Закупка
•Подготовка к внедрению
•Внедрение
•Корректировка
•Сопровождение
•Обновление и улучшение
•Вывод из эксплуатации
Метод Покупки Готового Решение (COST или «OFF-the-SHELF»)
COST или («OFF-the-SHELF» коробочное готовое решение) – Одним из подходов является покупка готовых решений. При покупке такого программного обеспечения организация должна:
•понимать достоинства и недостатки этого подхода;
•формализовать процесс выбора наиболее эффективного готового решения;
•определить процесс для эффективной интеграции и настройки готового решения;
•определить функциональные требования на приемлемом уровне;
•сформировать перечень управленческих и операционных требований;
•определить требования к продукту и поставщику;
•определить требования к интеграции услуги.
При покупке решения остается необходимость в:
•кастомизации (customization) – адаптация продукта под требования клиента, первоначальное конфигурирование, настройка интерфейса, изменение бизнес процессов и т п,
•локализация (localization) – язык интерфейса, перевод печатных форм и т п.
Основные преимущества – Покупка готовых пакетов программного обеспечения более экономична, часто более быстрое решение при выборе и внедрении. Может быть представленная клиенту как действующая «модель» или «прототип». Клиент уже на этапе выбора решения может иметь полную картинку возможностей и внешнего вида конечного продукта, имеющиеся ограничения и т п.
К недостаткам можно отнести – менее гибка, чем разработка собственных решений.
Концепция Информационной Безопасности
Общие Положения
Данный раздел содержит основные принципы архитектуры и информационной безопасности которые должны быть приняты во внимание. Раздел основывается на международных стандартах и практиках в области информационной безопасности, таких как серия ISO/IEC27000,
ISO/IEC27001, ISO22301:2012, ISO15408, ISO17799 (BS7799), NIST серии 800-хх, Information
Security Forum (ISF).


Диаграмма Концепция «Defense in Depth»
Задачи Информационной Безопасности
Обеспечения информационной безопасности способствует решению следующих задач:
•определение целей обеспечения информационной безопасности компьютерных систем;
•создание эффективной системы управления информационной безопасностью;
•расчет совокупности детализированных не только качественных, но и количественных показателей для оценки соответствия информационной безопасности заявленным целям;
•применение инструментария обеспечения информационной безопасности и оценки ее текущего состояния;
•использование методик управления безопасностью с обоснованной системой метрик и мер обеспечения разработчиков информационных систем, позволяющих объективно оценить защищенность информационных активов и управлять информационной безопасностью компании.
Необходимо определить приоритеты по критериям (Confidentiality, Integrity and Availability
CIA):
•Конфиденциальность (Confidentiality)
•Целостность (Integrity)
•Доступность (Availability)
Данные приоритеты требуется определить, как для организации в целом, так и для каждой ИТ системы.
Классификация информации и ИТ активов
Все ИТ активы и информация должны быть классифицированы с точки зрения безопасности по уровню конфиденциальности.
Обязательные требования для обеспечения конфиденциальности:
•Классификация данных.
•Наличие политики определяющий уровни доступа.
•Наличие процедур по работе с данными каждого класса.

Классификации данных может быть построена на основе следующих условий:
•Требования устанавливаются регулирующими органами.
•Требования определяются внутри компании.
•Классификация данных установленных регулирующими органами не может быть понижена
•Доступ к данным предоставляется по принципу «минимальных привилегий»
Классификация данных по уровню доступа:
Общего доступа – Могут быть опубликованы за пределами компании (например, перечень товаров и услуг, цены и т п)
Внутреннего использования – Документы предназначенные для сотрудников компании.
Утечка данных за пределы компании не наносят ущерба компании (процедуры, принятые в компании и т п)
Конфиденциальные – Данные содержат информацию, разглашение которой может нанести ущерб компании (репутации, финансовые потери и т п). Контроль за данными не регламентируется внешними контролирующими органами, но являются важными с точки зрения руководства компании (пароли к системам, контактные данные руководителей и т п).
Секретные
Данные регламентируются внешними контролирующими органами и разглашение которой наносит ущерб компании (репутации, финансовые потери и т п). к ним можно отнести финансовые данные клиентов и т п.
Классификацию данных необходимо проводить с представителями бизнеса и функциональных департаментов компании. Для определения информационных потоков и уровня интеграции данных необходимо провести классификацию данных информации по ряду атрибутов:
Зона покрытия – Данные локального значения и представляющие ценность для одной компании. Как пример; заказ столиков, обслуживание официантом в разрезе столиков/клиентов.
Данная информация может быть интересна для одной компании (отеля) и не представляют ценность для других компаний компании, наиболее востребованные комнаты, меню и т п может быть интересна для портфеля и т п
Зона видимости- Кому предназначены данные. Например, финансовые данные портфелей и компаний могут видеть только представители финансового департамента компании и правление, но представитель портфелей не видят информацию другого портфеля.
Тип данных – Бизнес информация или же техническая.
Владелец данных – подразделение или лицо, отвечающее за работу с информацией
(целостность и доступность). Необходимое контактное лицо для получения дополнительной информации и данных по процессу и т п
Классификация данных по ИБ – (коммерческая тайна, внутреннего пользования и т п).
Данные по клиентам, которые могут быть переданы компаниям компании или нет. (контактные данные клиентов отелей могут быть интегрированы в единую систему управления клиентами
(CRM) и в дальнейшем использоваться в маркетинговых целях для поиска потенциальных клиентов и т п)
Происхождение данных – Данные являются первичными, извлечены из бизнеса системы или же являются производными после проведения аналитических вычислений. Как пример имена, и контактная информация клиентов (Hospitality) может рассматриваться как первичные данные, а список потенциальных клиентов для Retail Group проанализированный в системе
(Hospitality) по ряду показателей (платежеспособность, количество потраченных средств, поведения клиента и т п) может рассматриваться как производные данные.
Источник данных – Веденный вручную оператором и наименование системы.