Игорь Якобсон
Письмо в редакцию
Когда фирма Ashton Tate выпустила первую версию DBase, она считала, что вопрос создания экономических программ (и не только их) решен раз и навсегда: их больше не будет! Останется только одна DBase, на которой конечные пользователи будут вести собственные базы данных, извлекая из них всю информацию, необходимую для анализа хозяйственной деятельности и принятия стратегических решений на ближайшее будущее.
Несмотря на то что некоторые основания так считать у разработчиков действительно были, к чему это привело на самом деле? Да к тому, что на рынке программистского (sic!) труда появился повышенный спрос на разработчиков приложений баз данных. Рядовой пользователь не справился с поставленной перед ним задачей.
Сегодня аналогичная ситуация сложилась с продвигаемым фирмой Microsoft стандартом Visual Basic. Он вроде бы предназначен для того, чтобы пользователь быстро пополнял новыми функциями такие популярные офисные приложения, как Word, Excel, Access, но... В американском перечне “Требуются...” специалисты по VB занимают ведущие позиции. Причем в их обязанности на рабочих местах ничего, кроме создания VB-приложений, не входит - какие уж тут конечные пользователи!
Тем не менее тенденция жива и процветает. И на отечественной почве тоже. В том числе и в области автоматизации бухгалтерии, экономики и финансов.
В самом деле, хочется ведь программистам создать “коробочный” тиражный продукт, который подойдет всем! А в условиях невероятного разнообразия учетных политик и стратегий бизнеса сделать это ох как непросто. Чтобы охватить все сегменты рынка, одна фирма должна создать десятки и даже сотни разных программных продуктов, да еще и дать пользователю в руки методику для правильного выбора того варианта, который годится именно ему.
Причем создание исходных текстов в безумном объеме - это цветочки, настоящие сложности возникают при сопровождении большого числа “жестких” программ в условиях постоянно меняющегося финансового законодательства.
Для квалифицированных ИТ-специалистов самым очевидным решением в этой ситуации является разработка универсального пакета со встроенным в него специализированным (“любой бухгалтер поймет!”) языком (будем его условно называть “бухгалтерским бейсиком”). А дальше, дорогие юзеры, все будет, как вы пожелаете, точнее, запрограммируете. Как отметил на закрытии конкурса “Бизнес Софт ’97” Евгений Шуремов (цитирую по памяти, так что прошу прощения за возможную неточность): “Такое впечатление, что уставшие от запросов пользователей программисты говорят: делайте, что хотите, только отстаньте от нас”.
Самыми яркими примерами такого подхода могут послужить популярные программы “1С” и “Инфо-Бухгалтер”.
Каков же результат распространения софта, поддерживающего подобную стратегию развития?
Во-первых, резко возрастает роль “посредников” между программистами и конечными пользователями, т. е. фирм, занимающихся внедрением ПО, к которым клиенты обращаются, убедившись, что не в силах освоить “бухгалтерский бейсик” самостоятельно. Соответственно растет и доля стоимости внедрения (которая и без того всегда была очень велика) в общей сумме затрат на автоматизацию предприятия. Это было бы нормально, но происходит дезориентация покупателя, который считает, что, купив ПО за пару сотен долларов, он решил все свои проблемы, а уже потом обнаруживает, что...
Создатель “1С” Борис Нуралиев честно предупреждает о сложившемся положении вещей, однако читают и слушают его в основном профессионалы, а не потенциальные клиенты, которые предпочитают самостоятельно наступать на грабли, а душу отводят, ругая разработчиков.
Второе следствие - резкое снижение быстродействия подобных программ.
Дело в том, что в руки непрофессионалу можно дать только интерпретатор. Что такое компилированный код, он, в массе своей, не поймет. Кроме того, необходимый пользователю анализ ошибок, возникающих во время выполнения, резко снижает быстродействие и в случае использования компиляторов.
Когда нужно ввести в язык какие-то новые возможности, очень велик соблазн также написать их на имеющемся “бухбейсике”. В результате в процессе выполнения программы для реализации пользовательских расчетов вызывается некая процедура, которая переводится в ряд более простых “бейсиковских” команд, а они в свою очередь вызывают процедуры обращения к базе данных, представляющие собой совокупность команд компьютера. И это еще упрощенная схема, на самом деле уровней иерархии значительно больше! А пока идет процесс многоступенчатой интерпретации, оператор раздраженно колотит кулаком по монитору. Для работы с плохим временем отклика нужны железные нервы!
Третье следствие прямо вытекает из второго. Пользователя всячески призывают покупать новую технику. “Смените компьютер”, или “добавьте оперативной памяти”, или “сделайте апгрейд винчестера” - “и все будет хорошо!” Так по мере развития ПО мы оказываемся втянутыми во все ускоряющуюся гонку, оплачивая ее своими кровными денежками. Идеи Билла Гейтса живут и торжествуют!
Все эти недостатки практически несущественны при автоматизации небольших предприятий со стандартной структурой учета - и быстродействия хватает, и внедрение из-за наличия готовых решений на “бухгалтерском бейсике”, созданных фирмами-посредниками в процессе обслуживания предыдущих клиентов, стоит не так уж дорого.
Но даже закупка самых дорогих компьютеров не способна решить проблему “интерпретатора на интерпретаторе” для систем корпоративного учета, оперирующих гигабайтами данных. Им нужны прикладные программные средства, в которых быстродействию повышенное внимание уделялось с момента написания первой строки исходного текста и даже задолго до этого момента.
И не верьте, что замена файл-серверной технологии на клиент-серверную решит все проблемы. Реальные испытания показали, что это происходит далеко не во всех случаях. Я бы даже сказал, что в большинстве случаев быстродействие не повышается. Почему? Это отдельный разговор.
Вот надежность работы действительно растет за счет хорошего обеспечения целостности данных современными SQL-серверами.
Имеются ли другие методы создания универсальных систем, кроме встроенных в прикладную программу интерпретаторов? Еще одним способом решения проблемы “активного пользователя” является распространение так называемых CASE-средств, логическим развитием которых я считаю средства визуального программирования. Вы не пишете программу, а собираете ее из заранее заготовленных (и оптимизированных) решений - кубиков. Покупатель получает СУБД и CASE-средства для построения приложений. Такую тактику предлагает, например, своим клиентам фирма Oracle. За счет оптимизации этих готовых кубиков и вызывающих их процедур быстродействие, как правило (но не всегда), повыше, чем при использовании интерпретаторов.
Визуальное программирование или CASE-систему освоить, с моей точки зрения, гораздо легче, чем тот же Basic, хотя и это требует определенных усилий. Но сия медаль также имеет свою оборотную сторону. Если таким образом создавать финансово-экономическое приложение “с нуля”, то многие вещи реализовать не удается.
Ничего удивительного: за все в мире приходится платить. За простоту создания приложений - неудобствами в интерфейсе. За универсальность - быстродействием.
Я бы сказал, что по аналогии с законом сохранения энергии существует закон сохранения объема работ по автоматизации предприятия. Можно только перераспределить задачи между исполнителями различных этапов проекта, к которым относятся и разработчики тиражных фирм, и представители компаний, занимающихся внедрением “коробочного” продукта, и сотрудники службы АСУ, и конечные пользователи системы. Что мы и видим в приведенном выше примере с “1С” и “Инфо-Бухгалтером”.
Получается, что качество тиражного продукта определяется тем, насколько удачно такое распределение было проведено. Надо буквально пройти по лезвию бритвы, спроектировав программную систему так, чтобы получившееся ПО, с одной стороны, не было слишком жестким, а с другой - не требовало для своей настройки (напоминаю, что часто под этим словом скрывается чистой воды программирование) окончания минимум полугодовых курсов с отрывом от производства.
Найти оптимальное решение этой проблемы стараются многие разработчики корпоративного ПО. Интересные, на мой взгляд, подходы демонстрируют “АйТи”, “Галактика” и “Монолит”, которые совершенно по-разному сочетают в своих программных комплексах готовые решения, визуальные настройки и средства доработки исходного ПО.
Свой вариант распределения обязанностей предлагает и санкт-петербургская фирма “Компас” в проекте “Компас + SQL”. Создатели системы закладывают основную массу расчетных алгоритмов на достаточно быстром языке Cи++, уделяя много времени оптимизации процедур. Пользователю не придется в очередной раз программировать на псевдобухгалтерском диалекте списание товаров по средним ценам, расчет подоходного налога или учетных цен по инвойсу и ГТД. Все это сделано заранее.
В результате “расфасованный” по коробкам продукт уже охватывает множество учетных политик и бизнес-стратегий, а не является оболочкой, которую еще нужно наполнять. Для тех же, кому чего-то не хватает, предусмотрены средства визуальной настройки - так называемые мастера: мастер таблиц и табличных форм, мастер экранных форм, мастер меню, мастер отчетов и документов. С их помощью можно изменить структуру базы данных, разработать удобный именно для вас способ визуализации информации на экране, быстро описать новые выходные формы или исправить имеющиеся в поставке бланки первичных документов и даже построить новое автоматизированное рабочее место. Такие возможности должны позволить решить свои проблемы подавляющей части “нестандартных” предприятий.
Для оставшегося же “ну совсем нестандартного” сектора рынка предусмотрен мастер SQL-запросов, на котором можно, с одной стороны, включить в пакет описание незапланированных создателями бизнес-процедур, а с другой - провести настройку на новый SQL-сервер, оптимизировав все запросы в соответствии с его технической документацией.
Вы думаете, я буду уверять вас, что это очень просто? Ничего подобного! Писать на SQL достаточно сложно. Все дело в том, что этот инструмент и не предназначен для конечного пользователя. Это оружие службы АСУ. Даже просто лицезреть на экране соответствующий пункт меню может только оператор, которому администратор системы выдал самый высокий уровень доступа.
С моей точки зрения, такое трехуровневое распределение функций, появившееся как некое усреднение результатов многолетнего общения с конкретными клиентами в процессе внедрения разнообразного ПО, позволит успешно сочетать в одном комплексе и достаточную степень готовности к использованию сразу после приобретения коробки с ПО, и гибкость в его последующем применении.
Ну а последнее слово в споре, кому из многочисленных разработчиков финансовых, торговых и корпоративных систем действительно удалось пройти по пресловутому лезвию бритвы, остается за пользователями. Судить им!
К Игорю Якобсону можно обратиться по адресу: sensr@kompac.spb.su.
