Автоматизация бизнес процессов

Вместо предисловия

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

Зачем нужны программисты

     Не сказать, что я древний программист, скорее молодое поколение, но я застал массовое внедрение в нашей стране в повседневную жизнь персональных компьютеров. Без преувеличения можно сказать, что на заре массовой компьютеризации самым популярным компьютером был Sinclar Spectrum 48. По началу это была маленькая коробочка на которой помещалась только клавиатура и светодиод индикации напряжения, даже блок питания был выносной и висел на розетке сети. Так вот самым плохим его свойством было то, что записывать данные можно было только на магнитофонную ленту. Это усложняло поиск нужных данных, снижало надежность записи и считывания (лента быстро выходит из строя) и увеличивало риск перезаписи нужных данных новыми. Так что первое и главное условие, которое я себе поставил при сборке своего Спектрума - это наличие флоппи диска. По крайней мере я смогу видеть каталог с файлами и манипулировать ими из специальных графических приложений. Это был шаг по лестнице прогресса к унификации и систематизации работы с данными. Ведь что нам нужно от компьютера - систематизацию наших знаний и быстрый доступ к ним. Зачем я привожу этот пример ? Да для того, чтобы показать принципиальное отличие хранения данных в базе данных от хранения их же на носителях в виде файлов. 
       Что нам дает каталог жесткого диска? Прежде всего, возможность создавать подкаталоги и файлы в них различной структуры. Таким образом была решена проблема систематизации данных, т.е. разбивка по темам и под темам и т.д. и т.п., а уже в отдельных темах создавать данные. Например, папка "Мои документы" - здесь хранятся все офисные документы пользователя. В этой папке есть каталог "Мои рисунки" - рисунки и фотографии, необходимые пользователю, "Приказы", "Факсы" и т.д. Файлы действительно могут быть любой структуры и это очень важно. Вам ничего не мешает поместить приказ в папку "Мои документы", где еще хранятся электронные таблицы и факсы. Это кажется обычным, нормальным явлением. Но вот, представим, что приказ был записан в каталог "Program Files", а по прошествии месяца -другого Вам его надо найти. Весьма печальная история. Это плохо, что Вам удалось туда его записать. Т.е. мы видим, что гибкость файловой системы не всегда является её преимуществом.
    База данных служит, в том числе, и для хранения данных. В чем принципиальное отличие базы данных от файловой системы? База данных - это файл или набор файлов, которые хранятся на носителе как обычный файл, но есть и принципиальное отличие. Этот файл имеет чрезвычайно сложную структуру, в которой может разобраться только сервер базы данных. Именно он и открывает этот файл на чтение и запись, а пользователь не имеет к нему доступа. В этом файле описаны данные, которые могут в нем хранится. Вам не удастся записать в него данные, которые он не может хранить. Более того, в этом файле есть правила поведения пользователя и ограничения на доступ к информации, т.е. правила секретности (security). Отсюда вытекает преимущество баз данных от хранения данных напрямую в файловой системе. Это преимущество - жесткая упорядоченность данных и полная их систематизация. Пользователь никогда не сможет нарушить правила систематизации, т.к. база данных ему этого не позволит. Пользователь может работать с этими данными в коллективе, а не только лично, т.к. правила на внесения и изменения данных регламентированы базой данных. Пользователь не сможет внести в базу данных некорректные данные, потому что база данных, на сколько это возможно, проверяет их корректность. Т.к. информация упорядочена, то легко можно найти нужные данные по отдельным признакам, и даже, по фрагментам признаков. 
    Вот поэтому, большинство руководителей организаций предпочитают хранить информацию о своем бизнесе в виде баз данных. Вот поэтому программисты баз данных нужны. Однако, Вы можете заметить, что программисты нужны время от времени, или даже только в начале создания организации. Это так для всего мира, но не совсем верно для нашей Родины. Наша страна - это большой эксперимент. В нашей стране все течет, все изменяется, поэтому нашим программистам намного больше работы приходится проделывать, чем дальне-зарубежным. 
    Необходимо поддерживать структуру базы данных согласно представлениям об объектах реального мира, необходимо переделывать отчетность, вносить изменения в бизнес правила и, наконец, тормозить цепную реакцию возникновения ошибок в программе, как расплату за частые внесения изменений. А когда проект программного комплекса вышел из под контроля полностью, то переделывать его заново, желательно, на новой технологии, которые, кстати, появляются так же часто, как грибы на лесной опушке после грибного дождика осенью. За всеми этими технологиями нужно следить, вовремя изучать и применять в своих разработках. Так что работы у программиста в нашей стране достаточно.

Правила поведения потенциальных покупателей на рынке программного обеспечения масштаба предприятия

    Первая мысль, которую необходимо обсудить - это стоит ли вообще выходить на этот рынок. Какие альтернативы у Вас есть? Прежде всего, стоит посмотреть как это происходит у "них". Обычно, и практика показывает, что это самый разумный способ, организация закупает программный комплекс в виде исходных текстов. При этом, лицензионное соглашение предусматривает, что покупатель не имеет права передавать тексты программ кому бы то ни было, иначе рынок бы рухнул в одночасье. Так вот, в этом программном комплексе, который покупается в виде исходных текстов, реализованы все возможные мыслимые и не мыслимые функции и отчеты работы пользователя, да так, что работать с такой программой практически невозможно, из за большого количества вводимых данных даже по самому тривиальному поводу. Например, чтобы завести товар на склад, Вам бы потребовалось открыть где-то порядка тридцати окон, в которых выбрать нужные значения характеристики товара. Моментально, после закупки, организация заключает договор с мелкой фирмой - 3-5 программистов, которые переделывают программу путем урезания функций под нужды заказчика. Эта фирма, как правило, лицензирована фирмой, которая написала программный комплекс. В дальнейшем, если изменится законодательство или расширится бизнес, можно снова нанять группу программистов, которые опять переделают программу. Это, по крайней мере, намного дешевле, чем закупать новую версию. А как это происходит у нас? А у нас соблюдение авторских прав - понятие весьма условное, поэтому никто Вам не продаст исходные тексты программы. Как правило, программы продаются в виде исполняемых модулей и библиотек, защищенные ключом электронной защиты. Эти программы, как правило, и это наиболее приемлемо, в определенных пределах могут настраиваться под Ваш бизнес. Для примера, можно взять 1С. Эта фирма выпускает программу для мелкого и среднего бизнеса, в которой реализованы возможности настройки. Далее фирма заключает договор с представителями, опять же, лучше, если лицензированными, фирмы, разработавшей программу или с самой этой фирмой на доводку программного комплекса под именно Ваши нужды. Т.к. переписывать исходники проще, чем реализовывать настройки программы, а исходники не продаются, то такие программные комплексы сразу "заточены", под наше законодательство. Теперь, когда изменится законодательство, Вам необходимо приобрести новые настройки или обновление, а если Ваш бизнес расширится, то возможно, придется докупить дополнительный модуль. Выходит, что покупатель программного продукта в нашей стране зависим от разработчика этого же продукта. Такое положение крайне невыгодно для организации. 
    Как же отличить откровенную сволочь, которая будет Вас доить от партнера? Первое правило - это предусмотреть в лицензионном соглашении наличие гарантийного срока эксплуатации, на протяжении которого Вы должны получать обновления программы бесплатно или за очень маленькие деньги 3-5 % от стоимости программы. Вы успеете окупить свои затраты на приобретение программы? Если с Вами хотят заключить договор на обслуживание и поддержку со стоимостью в несколько тысяч долларов, а за приезд специалиста на место установки программы брать отдельную плату, то это не Ваш партнер. Вам не стоит с ним заключать договора , и покупать программу. К тому же, Вам стоит навести справки о других пользователях этой программы, чтобы узнать их мнение, а особенно размер скидки при закупке новой версии программы для зарегистрированных пользователей. Скидка должна быть не менее 30%, иначе Вы будете вкладывать деньги не в Ваш бизнес, а в бизнес Вашего партнера. Лучше, если Вам удастся организовать что-то наподобие клуба пользователей. Возможно, Вам предложат срочно купить новую версию со значительной скидкой или с небольшой скидкой, но позже. Это нормально. Производитель программного обеспечения вкладывает большие деньги в разработку, поэтому ему выгоднее быстро вернуть их. И Вам выгодно купить дешевле, поэтому, если Вы собираетесь покупать новую версию, то разумнее купить ее сразу. 
    Однако, есть и альтернативный путь. Первое - это нанять программиста или небольшую группу программистов, которые напишут Вам программу под заказ. Ставьте перед ними задачи по порядку. Постепенно, они разберутся в Вашей специфике и станут более понятливыми и прозорливыми. Главное - это иметь хорошего специалиста по внедрению, который сможет направлять их работу и контролировать адекватность реакции программы на действия пользователя, т.е. сможет протестировать программу по всем правилам. Этот человек должен быть достаточно высокой квалификации. Он должен разбираться в технологии, которую использует разработчик. Возможно, он мог бы даже давать советы и оценивать качество программирования. Это в наших условиях самый простой и опасный путь, т.к. Вы в конце концов можете и не получить программу. Хорошо, если Вы не заплатили аванс. А то и потеряете деньги. Но если все пройдет нормально, то Вы станете обладателем исходных текстов и будете полностью независимы от разработчика. И тогда игра стоит свеч. Никогда не покупайте программу без исходных текстов от мелких фирм, а особенно от частного лица. Это чревато серьезными последствиями, т.к. такие разработчики, обычно не поддерживают свою программу, и продав ее однажды, больше не совершенствуют, и не занимаются переделкой. 
    Еще один вариант - это содержание штата программистов при организации. Этот вариант приемлем, если организация достаточно велика и автоматизация бизнес процессов на самом зачаточном уровне, или встал вопрос о полной переделке автоматизации бизнес процессов. В таком случае, при правильной организации труда, Вы достигните поставленной цели, возможно, немного дешевле при сравнимом качестве, а программисты пригодятся Вам и в дальнейшем для усовершенствования комплекса и перестройке его же при смене законодательства. К тому же эти специалисты могут выполнять заказы и "на стороне", если они не полностью заняты по основному направлению деятельности, что позволит снизить затраты на их содержание, а, возможно, и перевести на полную самоокупаемость, хотя это не может быть обязательным условием. Все зависит от загруженности Ваших специалистов текущей работой

Если бы был такой синтаксис SQL

    Еще на заре развития теории баз данных появилась т.н. теория двух Смитов. Где-то в начале 70-х годов всей мировой общественности на суд были представлены теоретические выкладки построения баз знаний объектно-ориентированных со всеми вытекающими от сюда наследованием, полиморфизмом и инкапсуляцией. Однако, никто не смог с налета реализовать эти теоретические выкладки. И победил Э. Кодд. Его реляционная модель легко легла в головы тогдашних гуру от программирования. Этот процесс породил, в конечном итоге, Всем нам известный стандартный язык SQL, и множество реализаций серверов баз данных с его использованием. Сразу хочу оговориться, что я могу ошибаться с датами, но порядок достаточно точен.
    Тем временем наука не стояла на месте. Накапливался опыт проектирования баз данных, совершенствовались компьютеры, языки программирования. Наконец-то и в них естественным образом научились создавать объектные типы данных. Вот, теперь и настал черед реализовать теорию Смитов.
    Надо сказать, что самые продвинутые разработчики не могли смириться с фактом своей беспомощности перед объектной ориентацией базы данных, к тому же маркетинговые ухищрения конкурентов, кричащих об объектной направленности своих разработок, заставили их, людей честных, заменить вектор направлений идеала с теории Смитов, которая теперь даже почти замалчивается, по крайней мере, в печати Вы ее не встретите, на т.н. "Инфологическую модель". Она является серьезным упрощением теории Смитов. Вообще "Инфологическую модель" полезно применять в процессе разработки программного комплекса, для систематизации своих представлений о проектируемой модели. Реализовывать же "Инфологическую модель" в виде программного комплекса крайне неразумно, т.к. это серьезно снижает производительность, и не дает почти никакого выигрыша в гибкости настроек программы. Я бы сказал так. В большинстве случаев, Вам не удастся создавать новые типы данных, кроме тех, которые можно создавать. А можно создавать те, которые запроектированы в программе. Например, программа "Бухгалтерия" будет создавать "новые" бухгалтерские документы, известные ей. Однако, связать эти документы в единый комплекс, Вам удастся в любых, самых изощренных, комбинациях.
    И вот, языки объектно-ориентированные, а базы данных - нет! Парадокс? Тогда то тут, то там Мы начали слышать, что, наконец, появился долгожданный сервер баз данных с "элементами" объектной ориентированности. Пока, все это только маркетинговые трюки. Не имеющие под собой никакого основания. Я бы мог предложить таким разработчикам новый синтаксис. Если они его реализуют, то тогда это будет настоящая объектная ориентация:

CREATE TABLE OFFICE_DOC(ID_NUM INTEGER, DATE_NOW DATE, IS_SIGNED CHAR(1), IS_PRINTED CHAR(1), IS_ARHIVED CHAR(1)); - создали потомка для других типов.

CREATE TABLE ORDER(OFFICE_DOC, TEXT BLOB); - наследовали от офисного документа приказ.

CREATE TABLE LETTER(OFFICE_DOC, ADDRESS VARCHAR(120), TEXT BLOB); - наследовали от офисного документа письмо.

SELECT OFFICE_DOC.ID_NUM, OFFICE_DOC.DATE, OFFICE_DOC.IS_SIGNED

FROM (ORDER, LETTER) AS OFFICE_DOC

WHERE OFFICE_DOC.IS_PRINTEG = 'F'; - здесь реализуется полиморфизм. Обратите внимание, что в один и тот же столбик выводятся данные из разных таблиц. А вот еще.

UPDATE (LETTER, ORDER) AS OFFICE_DOC

SET OFFICE_DOC.IS_SIGNED = 'T'

WHERE DATE_NOW = 'now'; - присвоение через предка. А вот еще:

DELETE FROM (LETTER, ORDER) AS OFFICE_DOC WHERE DATE_NOW < '01\01\2000';

А лучше иметь и такую конструкцию: DELETE FROM (*) AS OFFICE_DOC WHERE DATE_NOW < '01\01\2000'; - удаление из всех потомков.

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

Чего нужно опасаться

    Подытожим, чего нужно опасаться? Самое главное, чтобы программа или комплекс программ мог иметь возможность подстраиваться под Ваши нужды. Это увеличит срок морального устаревания комплекса автоматизации в целом. Второе, чтобы система была открытой, значит позволяла иметь доступ из других программ к внутренним данным. Это означает, что должен существовать интерфейс между закупленной программой и программами уже работающими у Вас или написанными в будущем. Обычно, это означает, что программа должна иметь либо интерфейс COM, CORBA или на худой конец, документированные процедуры обращения к базе данных. Далее, поставщик программного комплекса должен иметь практику скидок для зарегистрированных клиентов. Далее, Вам стоит прикинуть сальдо затрат и выигрыша от внедрения. Может так случиться, что Вы не успеете окупить программу. Программа должна окупится в течении не более года, т.к. в новом году нас постоянно ждет смена законодательства. Что значит окупиться? А это значит, что затраты на содержание персонала, естественно раздутого, без закупаемого программного комплекса, неэффективность принятия решений, волокита с отчетностью должна Вам стоить дороже, чем с программным комплексом и без всех этих проблем. Если Вы закупили программу, а штат не уменьшился, значит Вы ошиблись. Если Вы закупили программу, а принятие решений не стало более эффективным, значит Вы ошиблись. Если Вы закупили программу, а оперативно не можете получать все необходимые отчеты, значит Вы крупно просчитались! Руководствуясь вышеизложенными соображениями, Вы сможете выбрать из всех зол наименьшее. Идеальный вариант подобрать будет очень непросто. Возможно, в поисках партнера, Вы окончательно убедитесь, что нужно разрабатывать программный комплекс самостоятельно. Удачи Вам в поисках исполнителя. Но, тогда Вы вправе настаивать на приобретение исходных текстов. Помните о неизбежных переменах в законодательстве! 

Панацея от всех бед

     Пока, вышеизложенный синтаксис SQL не реализован в серверах баз данных, мы можем, в принципе обойтись и без него. Для этого строится трехзвенная база данных с использованием сервера приложений, на котором и будут реализованы все объектно-ориентированные принципы. Почему именно трехзвенная, а не "толстый клиент". Да потому, что правила доступа к данным и правила работы с данными должны быть инкапсулированы в процессе на сервере, а не у клиента, а иначе клиент может нарушать эти правила по своему усмотрению. К тому же, Вы получите COM интерфейс для связи других программ с Вашей базой данных.
    Немного не скромно, но это факт. Последнее время многие политики выступают с заявлениями, что наша Российская глубинка богата талантами. Один из этих талантов живет в славном городе Новороссийске. На протяжении вот уже нескольких лет этот человек, почти на голом энтузиазме, пишет программу баз данных, которая позволяет создавать базы данных любой структуры. Вы скажете, что в этом нет ничего необычного, и будете не правы. Было бы странно, если профессиональный программист баз данных не знал о концептуальной модели данных двух Смитов. Эти теоретики разработали общие положения строения модели знаний и их взаимосвязи между собой. Так вот, пока никому не удавалось в полной мере удовлетворить все требования такой модели данных. По крайней мере, я об этом не знаю и нигде об этом не пишут. Мне удалось построить модель данных, основанную на реляционной структуре, поддерживающую объектную ориентированность в полной мере. Это значит, что Вы можете без перекомпиляции программы, создавать новые типы данных любой структуры на основе уже имеющихся или заново. Вы можете работать с этими данными как с объектами, возможно, даже не подозревая об этом, т.е. в этой базе данных реализовано и наследование, и полиморфизм. К тому же структура этой базы данных не меняется при добавлении новых типов. Возможно, на этом месте Вы решите, что появился новый "Кулибин" со своим "Вечным двигателем". Немного терпения. Кстати, эта программа была представлена на выставке в г. Ростове, так что это не глупая шутка. Немного примеров. Что значит любые типы данных? Это значит, что Вы можете создать как бы таблицу, в которой в любом количестве и в любом сочетании столбики могут быть разных типов от целых, дробных и т.д. до документов OLE. Т.е. может быть пять целых, один дробный или денежный, два текстовых, ну и так далее или в другом сочетании. Некоторые столбики, по усмотрению, могут быть ссылками на данные другого типа, т.е. вычисляемые поля. Поддерживаются все уровни нормализации. Что значит объектно-ориентированная? Это значит, что вы можете наследовать свойства и методы одного типа от другого. При этом Вы сможете работать с наследниками как с родительским типом, т.е. поддерживается полиморфизм Например, Вы можете выбрать тип "Литература", заполнить поля для поиска, например, "Дата издания", "Авторы", и отметить что хотите искать и в потомках тоже. В результате выполнения поиска, будут найдены все типы, наследуемые из литературы, к примеру, "Журналы", "Книги", "Статьи", где выполняется условие поиска. Немного о методах. Каждому типу данных или любому свойству этого типа можно поставить в соответствие один или несколько методов, которые будут вызываться при наступлении некоторых событий, например создания, уничтожения типа или каких-то манипуляций при редактировании свойств. Так, Вы можете реализовать метод, который при перетаскивании записи, к примеру, "Получатель" в таблицу "Платежные поручения" будет автоматически создавать новую платежку с нужным получателем. Методы записываются на простом интерпретирующем языке, наподобие Бейсика. А теперь о самом главном. Так как структура базы данных не меняется, появилась возможность создать так называемых "Роботов". Роботы - это небольшие программные модули, которые могут получать команды посредством COM или DCOM и выполнять какой-нибудь класс работы. Т.е. Есть робот-печатник, который может быть настроен на печать любого документа в базе данных или робот - мигратор, который может копировать, удалять, редактировать и т.д. любые типы данных по программе, заложенной в его настройках. Например, Вы можете запрограммировать робот мигратор так, что он по утрам будет просматривать все неоплаченные входящие накладные и на основе сроков оплаты в контракте, создавать платежные поручения, после чего, пошлет команду роботу-печатнику, который их напечатает, а Вам останется только отнести платежки на подпись начальнику. Или что-нибудь в этом роде. Вот он - виртуальный офис в действии.
   Теперь немного о технологиях, на которых основан весь комплекс. Данные хранятся на стороне SQL сервера баз данных. Это может быть любой SQL сервер, т.к. это не принципиально или для энциклопедий и справочников локальные таблицы. Я настоятельно рекомендую Interbase 6.0, т.к. он самый простой в эксплуатации, у него самая правильная работа с транзакциями, самая верная система блокировок, он самый устойчивый к сбоям и он бесплатный, что снижает стоимость всего программного комплекса. Есть реализация и того и другого, по крайней мере первые опыты ставились на локальной базе данных. Вся структура комплекса представляет из себя клиент-сервер с тонким приложением пользователя, сервером приложений и SQL сервером. Сервер приложений, тонкий клиент и роботы общаются посредством DCOM или COM. Сейчас ведется разработка сервера приложений, который сможет общаться с тонким клиентом через Internet или напрямую выдавать HTML страничку или Active Form на запрос клиента для просмотра через браузер. Одновременно, совершенствуется код программы, чтобы добиться максимальной производительности при минимальной потребности в ресурсах клиента.
    Что нам дает такая база данных? Во первых, даже не получив исходные тексты программы, Вы получаете полную свободу в настройке Вашей программы под постоянно меняющиеся условия ведения бизнеса. Вы полностью свободны от производителя программного обеспечения. Более того, если Вам нужно автоматизировать весь бизнес процесс, то это возможно в одной базе данных, хотя, поддерживается и распределенная модель, состоящая из нескольких баз данных, которые видны пользователю как одна. Кто может сейчас заявить, что может в одном программном комплексе автоматизировать все в любой организации?