Сегодня поговорим о такой отрасли в сфере айти, как проектирование баз данных. Поговорим на литературном, инженерном языке, без программерских жаргонов и терминов, так, чтобы это было понятно читателям, не связанным с ИТ сферой. Здесь я дам общее описание самого процесса, из каких этапов оно состоит и кого привлекать для такой работы. Многие предприниматели (крупные предприятия уже давно это сделали) стремятся свести свое делопроизводство к удобному документообороту, создать единую базу хранения данных, хотя некоторые так и продолжают писать на листочках.
Основной физический смысл создаваемой компьютерной модели заключается в наборе необходимых для конкретных целей свойств и характеристик. Поэтому выбирая ту или иную модель приходится искать оптимальный баланс между простотой эксплуатации и достаточной информативностью.
На всех этапах проектирования той или иной информационной системы следует учитывать в первую очередь специфику, интересы и уровень подготовки простых пользователей, которые будут применять в своей работе созданное программное обеспечение. Интерфейс конечного программного продукта создается исходя из анализа документооборота той или иной организации, специфики работы, а также подготовленности конечного пользователя.
Основной критерий интерфейса должен стремиться к определению «чем проще, тем лучше», так как любая информационная система предприятия должна создаваться с целью оптимизации и упрощения рабочего процесса, а не с целью его усложнения. Приведу пример из практики работы механиком: для освоения нововведений в интерфейсе 1с, которые создала организация «для оптимизации учета ремонтных работ» механикам, мало того, что пришлось тратить лишние несколько месяцев на освоение этих новшеств, так еще и по итогу система сама по себе оказалась настолько кривой, что вести учет ручкой в тетради было намного быстрее и проще. Вместо оптимизации получили саботаж рабочего процесса.
Поэтому интерфейс конечного пользователя должен быть максимально прост и удобен для реализации типовых языковых запросов, печати необходимых форм отчетности, создания итоговых документов. Для этих целей как раз и создаются всевозможные инструменты в виде понятных систем меню, интегрированных средств обучения, программ–мастеров, всплывающих подсказок, помощников.
Исходя из вышеизложенного следует, что при создании той или иной информационной системы или проекта ключевыми звеньями являются две стороны. Во-первых, это конечный потребитель, то есть персонал и руководство предприятия, или, как обычно их называют сторона заказчика. Другая сторона — непосредственно разработчики программного продукта, работающие на основании технического задания. И между этими двумя сторонами посредник — а именно сторона отвечающая за информативное выявление потребностей заказчика, перевод его запроса в техническое задание, согласование сроков, объемов и стоимости работ и организация (распределение) работы в группе разработчиков. Часто в роли посредника выступает не один менеджер, а целый департамент или организация, состоящая из проджект - менеджеров, ИТ консультантов, аналитиков, администраторов и так далее, в зависимости от объема и сложности выполняемого заказа.
Исходя из основных свойств проектируемой системы, можно сделать вывод, что интересы программистов (стремящихся к максимальному упрощению модели) идут в разрез с интересами заказчика, который хочет получить универсальную информационную систему со множественным функционалом (как говорится «всё в одном флаконе»). И здесь очень важна одна деталь: чем более подробно и ясно определят свои цели заказчики, чем более четко они смогут сформулировать свой запрос, ЧТО именно они хотят получить на выходе, тем меньше впоследствии придётся делать исправлений программистам при написании кодов и последующем сопровождении (эксплуатации) конечного продукта и тем меньше дедлайнов и корректировок графиков будет у ИТ менеджеров.
В данном случае крайне важны переговоры, консультации, совместные обсуждения, в ходе которых заказчик наиболее четно описывает то, что он хочет в итоге получить. Понятно, что запросы и пожелания могут меняться уже непосредственно в ходе самой разработки и бывает так, что в ходе выполнения проекта заказчик вспоминает «еще одну очень важную деталь» и эту саму «деталь» на практике достаточно сложно интегрировать к проект. И тем не менее, здесь выявление запроса заказчика крайне важно на всех этапах проектирования. В процессе бесед и интервью разработчик формирует понятие о предметах, фактах и событиях, которыми должна будет оперировать данная БД, выявляет требования к ней рядовых пользователей (сотрудников организации).
Именно исходя из всех запросов заказчика (точнее всех его звеньев, от руководителя до рядовых офисных или технических работников) и формируется всем известное «Техническое задание» - документ, который подписывает руководитель (представитель) заказчика. На первом этапе программист разработчик формирует информационную модель понятной для будущих пользователей базы данных.
Начало проектирования состоит в описании предметной области, которое выполняется на простом привычном нам всем языке, а не на машинном. На данном этапе задействованы максимально все звенья как стороны заказчика, так и со стороны разработчиков. Совместной задачей является описание обычным языком самой сути базы данных, создание ее концептуальной модели.
Далее концептуальная модель переводится с языка «человеческого» на язык машинный. В итоге получаем так называемую логическую модель базы данных. Наконец, логическая модель посредством выбранной СУБД выводится на физический уровень, то есть переносится в память компьютера.
Немного перенесу вышесказанное на автомобильный бизнес. Многие спикеры сейчас проводят саммиты и тренинги по увеличению рентабельности и прибыльности автосервисов. Вижу, что в ходе таких дискуссий поднимается вопрос оптимизации и выбора опций CRM систем. Тут могу дать совет — при необходимости решения вопроса, связанного с ИТ системами, обращайтесь к профессионалам.
Лучше, если это будут сами компании разработчики программного обеспечения. Как правило, в этих компаниях имеются и консультанты, и разработчики, и организованная техподдержка. Всем успешного бизнеса и продуктивных трудовых будней!). И да, отвечу на вопрос, почему раньше были статьи про диагностику, а теперь про айти. Всё очень просто - я не стою на месте, двигаюсь дальше. Получила образование в сфере ИТ и применяю полученные знания на практике.