На этой, немного более подробной, диаграмме показано необходимое и достаточное количество информационных модулей для ведения бизнеса.

Расширенная универсальная информационная схема бизнес-активности

При разбиении функциональных блоков на более мелкие - обнаруживаются новые информационные сущности. Назовем диаграмму - Управление Данными. Как видно на схеме, из функциональных блоков тянутся стрелки к информационным блокам.

Бизнес Модуль

Проанализируем для начала Бизнес Модуль (BM) и пойдем по стрелкам от BM к Employees и Contractors. Только эти информационные сущности, действующие лица, связаны непосредственно с осуществлением бизнес-операций.

Имеется стрелка, указывающая на Safety Management. В современном мире бизнеса это одна из важнейших его составляющих. Без обеспечения безопасности и качества работы невозможна никакая успешная трудовая деятельность.

Есть стрелка, падающая на Production Management, база знаний о специализации бизнеса, свод правил и приемов работы, описание последовательности операций и т.п.

Последняя стрелка указывает на блок Анализа продаж товаров или услуг бизнеса, собственно механизм контроля успешности бизнеса.

Людские ресурсы

Под непосредственным контролем этого блока находятся информационные сущности Employees и Contractors. Как уже было сказано выше, это буквальные мускулы бизнеса физические и умственные. Блок управляет людьми и их взаимоотношениями с бизнесом. Чем же они отличаются? В случае Employees наемные работники принимаются на постоянную или временную работу в компанию, компания платит им регулярную зарплату, выплачивает различные бонусы и пр., берет на себя управление налоговыми отчислениями работников, в случае Contactors исполнитель просто осуществляет какую-то необходимую операцию бизнеса, которая не является основным процессом бизнеса, самостоятельно рассчитывается с государством в отношении налога на прибыль.

Адресные данные и Контакты

Если приглядеться внимательно к Employees и Contractors, то обнаружится некая общая сущность, объединяющая людей из этих разных блоков в Addresses and Contacts. И в том и в другом случае работник имеет некое место жительства и контактные данные. Вот мы и дошли до самого нижнего информационного блока, обеспечивающего нужными данными запросы по стрелкам с самого верха управления.

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

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

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

Из области общих знаний всем более-менее известно количество стран во всем мире, около 232 ( из-за событий слияния, разделения число - не постоянная величина). Из практического опыта построения адресных систем обнаружилось, что внутри каждой страны всегда имеются ведущие административно-территориальные деления, известные как район, провинция, штат и т.п., и их примерно 4567 во всем мире плюс-минус около 100 из-за постоянных пертурбаций с переименованиями, разделениями и слияниями. Что же касается учета более детальных подразделений географического адреса, то здесь уже цифра зашкаливает за миллионы. Однако ничего страшного, каждый населенный пункт имеет своего "родителя"- район, каждый район имеет "хозяина" - страну, поэтому задавая 3 единицы информации, можно однозначно ассоциировать населенный пункт с определенным человеком или организацией.

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

Думается, что схематическое представление вышесказанного лучше всего продемонстрирует простоту взаимоотношений единиц адресной информации.

Универсальная схема базы данных для хранения любых адресов

Поле PlaceType в таблице Places для определения типа населенного пункта, поскольку часто случается, что в районе/штате/провинции встречаются разные типы населенных пунктов с одним и тем же названием. Таблица Continents добавлена для удобства группировки и фильтрации данных. Для того чтобы довести создание схемы до логического завершения необходимо добавить детальную таблицу, в которой обычно хранятся данные о субъекте - Addresses. Как вы догадались, субъектом (мы сейчас говорим о поле Id_Object в таблице Object_Addresses) может выступать как Employee, так и Contractor. Более того, этот принцип хранения данных подходит и для управления данными о клиентах (Clients), поставщиках (Vendors), конкурентах и так далее. В реальности не существует абстрактного клиента, обычно имеют дело с одушевленным представителем клиента, то есть конкретным человеком. Адресные данные для таких случаев можно элементарно хранить в представленной базе.

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

Аналогичный принцип разбиения информации на смысловые блоки применим и к области контактных данных людей. Она получится немного проще, но не менее мощной в плане ценности консолидации данных для различных анализов. Необходимо иметь справочную таблицу типов оперативной коммуникации - ContactType, в которой можно хранить: "Телефон", "Мобильный", "Факс", "Email", "Скайп",.. Нужна таблица Contacts для непосредственного хранения самих телефонных номеров и адресов почты, позывных скайпа и так далее. И третья таблица Object_Contact, аналогичная той, что в адресной схеме.

Универсальная схема базы данных для хранения любых контактов

Теперь достаточно завести таблицы учета самих субъектов: работников, контракторов, клиентов и т.п. и передавать указатель на уникальный номер записи соответственно в таблицу Object_Address и Object_Contact. Как видите, никакой сложности не наблюдается. Зато обеспечивается максимальная гибкость и преимущество этой системы перед некоторыми известными творениями бездарных ремесленников от программирования (не будем указывать пальцами - многие, дочитавшие до этого места - поймут). Данный подход не ограничивает разработчика программного обеспечения в сфере управления CRM тремя-четырьмя жестко запрограммированными колонками таблицы базы данных, отведенных на адреса и контакты субъектов! В предлагаемой модели информационной базы нет ограничений на количество адресов и контактов, ассоциированных с одним человеком или объектом.

Более того, применение такой модели в прикладном решении для одного из клиентов позволило обнаружить двойной расход финансовых средств за определенный период, выделенных на исполнителя, выступавшего одновременно как наемный работник и как контрактор, за счет локализации одного и того же адреса для обоих объектов! Выводы делайте сами.