19.04.2012

Отчуждаемый продукт

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

С. Проскурин
Генеральный директор фирмы "ЛокИС"
Журнал "Бухгалтер и компьютер"
№11 2002.
Рубрика "Практика автоматизации".
Мнение о том, что ни один программный комплекс
не может обходиться без поддержки программиста,
- это вроде бы почти аксиома, с которой вряд ли
кто решится спорить. Безусловно, основания для
такого утверждения есть. Однако, как это ни покажется
удивительным, есть и исключения.
Интегрированная система "ЛокОФФИС" -
 пока единственное из таких исключений.
Во всяком случае, другой подобный опыт не известен
и редакции "БиК", тем более что этот продукт изначально
разрабатывался как система комплексной автоматизации
для торговой фирмы.




История
Впервые ИС "ЛокОФФИС" была представлена на рынке как самостоятельный продукт в сентябре 1992 г. на выставке Softool'92. Его разработка была выполнена на базе заказного проекта "Системы комплексной автоматизации торговой фирмы "Терминал Плюс". Об этой системе был снят материал на фирме-заказчике, его показали потом в телепередаче Ю. Пухначёва "Терминал". Для фирмы "ЛокИС" это была уже третья реализованная комплексная система (первую показали ещё на Softool'91). Так как других комплексных систем на выставке не имелось, она выглядела диковинкой. Каждому посетителю приходилось объяснять отличие сетевой комплексной системы, работающей с единой базой данных, от традиционного набора АРМов.

Развитие продукта
Эволюционность развития против революционной смены платформ
В конце 1992 г. многим стало понятно, что условия жизни в нашей стране изменились радикально и надолго. Стало это ясно и работникам "ЛокИСа". Получив заказ на разработку комплексной системы для торговой фирмы, мы думали, что это будет одним из направлений нашей деятельности (и, конечно, не основным). Тресты, объединяющие несколько управлений, представлялись нам тогда главными потребителями услуг комплексной автоматизации. Однако закат советской системы и социалистических принципов хозяйствования заставил поменять мнение и подход к разработке. Успех системы для торговли показал, что она ещё долго будет "двигателем прогресса" и останется основным заказчиком подобных систем. Обсудив эту ситуацию в коллективе, мы приняли решение развивать и довести созданную систему до состояния, так сказать, полной отчуждаемости. Ясно было, что условия хозяйствования и "правила игры" в стране будут меняться, а значит, и продукт должен обладать такими свойствами и способностью к модификации, чтобы заказчик мог его осваивать и эксплуатировать практически без участия разработчика.
Так как с самого начала предполагалось долговременное развитие системы, остро встал вопрос о выборе надёжных и перспективных инструментальных средств разработки и системы управления базой данных.
После непростых поисков и прикидок были выбраны соответствующие средства: язык программирования "Си" и СУБД для разработки приложений на "Си" Raima Database Manager американской фирмы Raima Corp. (в то время она называлась db_Vista Ш).
Ещё один немаловажный - человеческий фактор. В любом коллективе на начальном этапе собираются специалисты с различным опытом и вкусовыми привязанностями. На это накладываются специфические черты характеров людей, их амбиции, что нередко довольно сильно мешает работе, не позволяет сформировать слаженную, дружную (это очень важно) команду разработчиков, без которой нельзя создать сколько-нибудь серьёзного продукта.
Непросто протекал этот процесс и у нас, но постепенно все напряжённые проблемы производственных отношений были сняты с повестки дня.
Есть ещё один существенный фактор, который подтолкнул многие коллективы пойти иным путём. Когда начинается разработка, особенно в рыночных условиях, обычно присутствует стремление завершить её как можно быстрее. Но разработчику, так же как легкоатлету перед забегом, имеет смысл определиться: на какую дистанцию он "побежит" (как в песне у Владимира Высоцкого: "...я ж на длинной на дистанции помру, не охну!.."). Нужно оценить и понять, как долго сможет продержаться "на дистанции" его детище (программный продукт), какие изменения и катаклизмы его ждут, хватит ли духу и его качеств для длительного марафона. Если это разовая задача с чётким техническим заданием, можно использовать любые адекватные ей средства. Однако круг доступных к использованию средств значительно сужается, если разработчик планирует длительный цикл использования созданных программ в быстро изменяющихся условиях или постановка задачи не обладает исчерпывающей полнотой. В таком случае следует использовать инструмент, отличающийся максимальной гибкостью и дающий максимальную свободу разработчику.
Не могу удержаться от аналогии. В строительстве в советское время, да и сейчас, основной технологией было крупнопанельное строительство. Эта технология позволяет возводить дома дёшево и быстро, но они получаются до уныния однообразными, да и с качеством у них имеются некоторые проблемы. Кирпич и монолитный железобетон, используемые в цивилизованных странах и в нашем так называемом элитном строительстве, дают практически полную свободу архитектору и не имеют "родовых травм" панельного строительства. Но дома, возведённые по такой технологии, строятся значительно медленнее и стоят дороже. То же самое - в информационных технологиях: если использовать так называемые высокоуровневые (применительно к строительству - крупнопанельные) инструментальные средства, результат будет получен быстрее и дешевле. Но реализация некоторых простых вещей и технологических нюансов оказывается весьма затруднительной без применения в разработке средств низкого уровня. Особенно много проблем неизбежно возникает при длительной эксплуатации подобного продукта. В конце концов они вынуждают руководство фирмы прекратить его развитие, оставив овеществлённый в нём опыт, и начать новую разработку на новых средствах. Собственно, это и произошло с абсолютным большинством отечественных решений. Возвращаясь к интегрированной системе "ЛокОФФИС", заметим, что её развитие ведётся практически на тех же средствах, что и 10 лет назад. Это та же СУБД Raima Database Manager (только последняя версия) и тот же язык программирования "Си". Сейчас система содержит 60 модулей, объединённых в 9 подсистем.
Некоторые фирмы (разработчики) успели за это время несколько раз поменять свой инструментарий.
Опыт против сочинения модели
Говоря о развитии программного продукта, зададимся вопросом, что же представляет собой компьютерная программа для автоматизации управления на предприятии? Вопрос несколько философский, но в нашем случае ответ на него будет такой: компьютерная программа - это инструмент для получения решения некоторой интеллектуальной задачи, сформулированной человеком, посредством использования технических средств.
Программные системы состоят из набора взаимосвязанных программ, ориентированных на применение в какой-либо сфере. Набор задач, решаемых человеком в той или иной области, не остаётся постоянным. Со временем в зависимости от ситуации меняются и приёмы решения задач. Поэтому теоретически невозможно создать набор истинных устойчивых инструментов для адекватного отражения технологических потребностей на протяжённом отрезке времени.
На практике возможны два подхода для разработки таких систем:
•   сочинить (или разработать) модель так называемых бизнес-процессов предприятия и во плотить её в программах;
•   отразить в программах опыт деятельности предприятия путём анализа и реализации пожеланий сотрудников.
Добросовестная, корректная реализация первого подхода требует обязательной разработки методов, которые позволят оценить степень адекватности созданной модели описываемому ей объекту. Помимо этого должны быть оценены допустимость принятых упрощений и возможность использования созданной модели в реальной практике. Сомневаюсь, чтобы это где-то выполнялось. В реальной жизни, даже если разработчик сочиняет вначале модель, она потом корректируется исключительно практикой применения.
Поэтому мы сразу выбрали второй подход, который привёл к некоторой эклектичности системы, зато упростил её понимание и освоение. При знакомстве с системой на выставках посетители нередко говорят нам, что система "сделана по жизни".
Нельзя утверждать, что такой подход не имеет издержек. В системе сохраняются некоторые явно устаревшие, на взгляд разработчика, средства, но изъять их оттуда не всегда удаётся. Почти каждый раз, когда делались подобные попытки, находился кто-то из пользователей, кому именно эта справка или режим оказывались крайне необходимыми, и они требовали вернуть их в систему.
Скорее всего истина в подходе к разработке находится посредине.
Накопив за десять лет обширный материал по отражению потребностей определённой отрасли в программном продукте, мы можем поставить задачу по его исследованию, поскольку он уже формализован по определению. На основании такого исследования можно разработать модель и уже её реализовать в новом продукте. Видимо, этот вариант и будет претворён в жизнь в дальнейшем.
Преемственность интерфейсных приёмов работы
Разрабатывая Windows-версию системы, мы никогда не упускали из виду, что переход на новую платформу - это обычно непростой, длительный и болезненный процесс. К моменту выхода Windows- версии в 1999 г. на некоторых предприятиях использовали прежний вариант (DOS-версии системы "ЛокОФФИС") более пяти лет, и мы не считали себя вправе заставлять эти предприятия, этих пользователей вкладывать существенные средства, связанные с изменением приёмов работы и переобучением сотрудников.
Помимо этого есть ещё один аспект, неблагоприятно влияющий на разработку при смене платформы. Новый проект на новой платформе, как правило, начинается новой командой специалистов, при этом теряется накопленный неформализованный опыт предыдущей разработки. Этот опыт включает в себя наиболее существенные элементы системной разработки - связи и проверенные алгоритмы взаимодействия не только между модулями системы, но и между самими её создателями. Поэтому практически ни одна из команд, выпустивших новый продукт на новой платформе, не сохранила функциональной полноты и согласованности, свойственных предыдущей платформе. В дальнейшем приходится наверстывать упущенное, но уходит время, а нередко и клиенты.
Понимая это, мы создали Windows-версию, полностью адекватную DOS-версии, но только с графическим интерфейсом. Пользователь может параллельно использовать одни и те же модули с одной и той же базой на разных платформах. Несомненно, что, приобретая в одном, приходится терять в чём-то другом. Необходимость поддерживать две идентичные платформы не позволяла нам использовать все интерфейсные возможности и преимущества графической среды. Зато это дало возможность нашим клиентам растянуть процесс обновления парка компьютеров на четыре года, что сэкономило им значительные средства. Только этим летом мы приняли мягкие экономические меры по "добровольно-принудительному" переходу клиентов с платформы DOS на Windows-версию путём повышения им ставки сопровождения при использовании DOS-версии.

Функциональный охват предметной области
Первая реализация комплексной системы
Как уже говорилось, первая версия системы была реализована по заказу. Мы воплотили в ней все пожелания конкретных сотрудников конкретной фирмы. В те годы новая экономика только зарождалась, и сотрудники торговых фирм в своей предметной области разбирались немногим лучше разработчиков, тем более что значительная часть коммерсантов первой поры вышла из инженерного корпуса советской эпохи. Пожелания заказчиков были понятны разработчикам и достаточно легко формализовывались и переносились в тело программ. Мы думали, что первая реализованная система обладала исчерпывающей полнотой. Но оказалось, что жизнь гораздо многообразнее, и не все люди делают одну и ту же работу одним и тем же способом. Как сказал бы великий, чем больше я знаю, тем больше вижу, что я не знаю. Если бы в системе оставался тот же набор функций, она вряд ли сохранила бы по сей день ту же привлекательность, что и в первые годы.
В начальный период выхода на рынок ИС "ЛокОФФИС" мы ещё вели заказные работы и предполагали развитие по этому направлению. Но с каждой продажей системы мы узнавали всё новые потребности пользователей, не учтённые в программах.
Тогда и было принято решение не форсировать продажи, а развивать систему как продукт. Поэтому в первые три года для сдерживания (!) этих продаж пришлось почти каждый месяц поднимать её цену. Такое решение кажется нелогичным, так как противоречит основополагающей цели бизнеса - получению максимальной прибыли. Но это только на первый взгляд. Если выпекать пирожки, то действительно следует в кратчайшее время максимизировать продажи и минимизировать цену, пока они "не остыли". Но систему такого масштаба, как "ЛокОФФИС", нельзя создать за один приём и распродавать, как пирожки.
Сбор, обработка и анализ пожеланий пользователей
Истина - это процесс, утверждали классики. Чтобы система во всё большей степени отражала потребности предприятий и пользователей, были налажены сбор, обработка и анализ их пожеланий. Это совершенно необходимая часть процесса на пути совершенствования системы.
Дело в том, что пользователи обычно высказывают значительно больше пожеланий, чем на самом деле следует воплощать в жизнь. Приведём конкретные цифры. В нашей внутренней системе версионной поддержки и развития продукта накоплено свыше пяти с половиной тысяч пожеланий пользователей, из которых уже реализовано примерно три с половиной тысячи. Около пятисот находится в процессе реализации, примерно столько же имеется пожеланий, решение по которым пока не принято, и около тысячи пожеланий не будет реализовано никогда. Отказ от реализации - это не наш каприз. Как показывает анализ, часть пожеланий не может быть реализована "в принципе", часть может привести к нежелательным последствиям в дальнейшем, а часть просто говорит о непонимании некоторыми пользователями сути происходящих на предприятии событий.
Чтобы можно было сделать такие выводы, необходимо разбираться в реальных процессах на автоматизируемых предприятиях. Некоторые из наших коллег-разработчиков берут для этого на работу квалифицированных консультантов или заключают партнёрские соглашения с консалтинговыми фирмами. Мы же решили глубоко изучить и освоить одну отрасль - торговлю и, собирая и анализируя потребности своих клиентов, самим приобрести необходимый опыт. Тогда в конечном счёте наши услуги обходятся клиенту дешевле.
Приоритет реализации оплаченных пожеланий
Система "ЛокОФФИС" развивается по нашему внутреннему плану на основе пожеланий клиентов. Но иногда у пользователя возникает потребность, которую ему надо удовлетворить срочно, и за это он готов заплатить. Такие пожелания мы рассматриваем вне очереди и в случае их реализуемости запускаем "в работу" вне плана. В этом проявляется не страсть к наживе, а понимание потребностей клиента. Если он готов заплатить, значит, разработка ему действительно необходима. Филантропов среди наших клиентов нет.

Внедрение без разработчика
Концептуальное требование к разработке
С самого начала деятельности нашего предприятия мы приняли решение разрабатывать продукты таким образом, чтобы они могли отчуждаться, т. е. эксплуатироваться пользователем собственными силами. Сегодня в отрасли доминирует иная точка зрения: продукт - это поводырь разработчика, куда система попадёт, туда и пойдёт он зарабатывать деньги. Исследование предметной области (или, как сейчас модно говорить, бизнес-процессов), обучение, внедрение, консалтинг, сопровождение и прочие виды деятельности фирм-разработчиков приносят доходы, сравнимые со стоимостью самих продуктов, а то и многократно превышающие их.
Однако в этом смысле мы остались на своих прежних позициях и до сих пор за все десять лет ни разу не внедряли свой продукт. В нашем прайс-листе нет услуг по внедрению, консультированию, обучению и т. п. Всё, что необходимо пользователю, содержится в самом продукте и технической документации к нему. А разработка ведётся таким образом, чтобы обеспечить непререкаемую надёжность системы. За время использования наша база данных ни разу ни у одного пользователя не обрушилась, хотя, конечно, ошибок в программе избежать не удаётся. Программа может сбиться, но база - никогда!
Технологии внедрения: демо, "гусарик", "эскадрон", VIP-версия
Когда на выставке приходится рассказывать посетителям о том, что наш продукт внедряют сами пользователи, нередко видишь скептическую усмешку. Действительно, "верится с трудом". Но только до тех пор, пока посетитель не знает ни продукта, ни технологии, позволяющей осуществлять такой процесс.
Знакомство с нашей системой обычно начинается с демонстрационной версии, размещённой на сайте компании "ЛокИС". Там выкладывается несколько устаревшая версия, но её вполне достаточно, чтобы получить представление о функциональном наполнении системы, её интерфейсе, основных приёмах работы.
Если система заинтересовала потенциального пользователя, он обращается в нашу компанию или к её представителям на выставках, в которых мы принимаем активное участие не только в обеих столицах, но и в регионах. Там он получает дополнительные консультации и разъяснения, что позволяет ему определиться с приобретением. Если решение купить уже созрело, но деньги тратить пока не хочется, потенциальный клиент приобретает специальную "гусарскую" версию программы. Она включает в себя однопользовательскую версию основной подсистемы "ТОВАР" без каких-либо защит и ограничений и демонстрационную "свежую" версию всей системы. Это полноценный продукт, несмотря на его "смешную" цену в 500 рублей. Он выпущен нами для того, чтобы будущий пользователь мог не спеша, не затратив значительных средств, узнать все возможности системы, попробовать настроить её под специфику своего предприятия, провести на ней обучение сотрудников и даже осуществить наполнение базы данных и начать реальную работу на ней, если объём ретроспективных данных не слишком велик (до 20 тыс. записей). Другими словами, "гусарик" даёт возможность, не вкладывая заранее и вслепую серьёзных денег, осуществить всю необходимую подготовительную работу для внедрения системы, попробовать её в работе, а также провести анализ системы и принять полноценное решение о целесообразности её приобретения и использования.
Когда подготовительная часть работы выполнена и нужно вводить большой объём ретроспективной информации, а денег тратить всё равно не хочется (или пока нет возможности), наш клиент может приобрести ограниченные версии на 5 и 10 одновременно работающих сессий (мест) в сети по специальной цене 600 и 1600 долл. соответственно. Эти версии (получившие условное называние "эскадрон") дают возможность одновременно вводить ретроспективную информацию в базу данных предприятия и отрабатывать взаимодействие сотрудников с использованием основных возможностей системы. В чём ограничения этого варианта? Только в составе модулей: в эти версии включены лишь основные подсистемы "ТОВАР", "БУХУЧЁТ", "ПЕРСОНАЛ" и "ПРЕРОГАТИВЫ ДОСТУПА", причём разработчик не предоставляет услуг по их сопровождению. Сначала эти ограниченные версии мы разработали для регионов, чтобы максимально снизить цену и создать истинно "коробочный продукт", т. е. полностью отчуждаемый от разработчика. Использование этих версий для внедрения подсказали сами пользователи.
Наконец, когда пользователь системы "ЛокОФФИС" внедрил и освоил основные возможности системы, у него появляются дополнительные потребности. Ему могут понадобиться консультации разработчика по использованию продукта для оптимизации процессов управления на предприятии, реализации некоторых существенных для него режимов или справок, какие-то из дополнительных модулей или подсистем. В этом случае он приобретает уже "VIP-версию", доплачивая лишь разницу в стоимости вариантов.
Такая последовательность вовлечения продукта в деятельность предприятия минимизирует инвестиции заказчика и максимизирует отдачу от вложенных средств.
Статьи, online-руководства пользователя и другие средства помогают клиенту освоить систему без обращения к разработчику. В крайнем случае можно связаться с разработчиком по "горячей линии" и получить квалифицированную консультацию из первых рук.

Работа без программиста
Обычно процессом внедрения системы на предприятии занимается специальный человек, реже два. Подобного сотрудника мы называем администратором системы, хотя это может и не соответствовать названию его должности. У наших клиентов таким человеком оказывался и генеральный директор, если предприятие небольшое, и (или) программист, если такова была должность человека, когда внедрялась система. Большинство подобных программистов после её внедрения становились начальниками отделов учёта, заместителями руководителей фирм. Хотя есть примеры достаточно крупных торговых компаний, где администрированием системы занимаются заместители генерального директора и финансовые директора. Это объясняется тем, что система не требует программистской поддержки. Всё техническое администрирование сводится к простым автоматическим процедурам копирования и проверки целостности базы.
Описания, руководства и справочные пособия дают клиенту возможность решить практически любой вопрос по эксплуатации системы самостоятельно. Мнемонические настройки режимов в системе позволяют перенастроить её для других условий работы, отличных от первоначальных, также без помощи программиста.
При помощи имеющихся в системе и не требующих программирования редакторов печатных форм и конструкторов отчётов менеджер, бухгалтер или другой работник фирмы-пользователя может сам создать и использовать необходимые формы документов и отчётов.

Цена автономии
Для обеспечения автономной эксплуатации малоквалифицированными в системном плане сотрудниками были использованы специальные архитектурные решения. В частности, система осталась в архитектуре "файл-сервер", хотя уже в 1996 г. был создан и клиент-серверный её вариант. Что касается последнего, то мы (после проведения сравнительного анализа) окончательно пришли к выводу, что он не имеет преимуществ ни в скорости расчётов, ни в стоимости технических средств. Вопрос об использовании клиент-серверных технологий задаёт практически каждый второй посетитель на каждой выставке, что, на наш взгляд, является следствием массированной, но при этом не слишком вдумчивой рекламной кампании, уже много лет идущей на страницах околокомпьютерной прессы.
В немалой степени этому поспособствовали наши коллеги, переходя от своих ранних продуктов, реализованных на инструментальных средствах типа Fox, Clipper и т. п., к продуктам на основе MS SQL или к иным столь же "мощным". Этим намеревались подчеркнуть их перспективность, современность и необходимость для пользователя. В качестве основного рекламного аргумента новизны они стали указывать принадлежность своих новых продуктов к технологии "клиент-сервер".
Не надо быть семи пядей во лбу, чтобы понять простую архитектурную коллизию: если на предприятии в локальной сети полсотни примерно равных по производительности персональных компьютеров, включая сервер, не стоить отдавать ему всю прикладную обработку и этим делать из остальных столь же мощных станций "компьютерных трутней", устанавливая на них "тонкого клиента". Единственный аргумент, который приводят адепты клиент-серверных технологий в нашей стране, формулируется как необходимость при файл-серверной технологии перекачивать на рабочую станцию всю базу. Во-первых, это не так - при разумном подходе к проектированию структуры базы. А во-вторых, использование современных сетевых средств позволяет копировать информацию по сети со скоростью, превышающей копирование в локальной машине.
Дэвид Васкевич в своей книге "Клиент-серверные технологии" даёт несколько десятков определений и полсотни аспектов этой обширной проблемы, о большинстве из которых соискатели подходящих программ на рынке не имеют даже отдалённого представления. Просвещение их в этой области не является задачей данной статьи. Важно отметить, что мы сознательно остановились на используемой нами технологии, считая, что она не имеет себе равных по производительности (кстати, и по цене) в области автоматизации торговых предприятий.
Использование этой технологии снижает стоимость программы, поскольку к ней не надо добавлять отчисления за использование ядра СУБД. Клиенту не нужно содержать специально обученный квалифицированный персонал для поддержания ядра СУБД.
Как разработчики прикладного продукта, мы независимы от разработчика СУБД, поскольку приобрели её в исходных текстах.
Быстродействие, простота инсталляции системы и сопровождения, отсутствие потребности у клиента в квалифицированных программистах приводят к существенному снижению стоимости владения системой. Наверное, поэтому за десять лет от её использования отказалось значительно менее одного процента приобретших её.

Инструмент в руках дикаря - кусок металла!
Очень хочется сказать несколько слов для той малой части иногда встречающихся пользователей, которые воспринимают любую систему автоматизации как средство избавления работников на предприятии от "трёх печальных необходимостей":
•   каждый сотрудник должен знать, что он делает на предприятии;
•   каждый работник, прежде чем совершить то или иное действие, должен подумать, для чего он его совершает;
•   сотрудник должен нести ответственность за совершённые им действия.
Так вот, никакая система автоматизации не возьмёт эти "необходимости" на себя! 

     Программа LokOFFICE, уникальна на рынке по своей надежности. С самого начала т.е. с 1992 года, программа поставлялась в готовом виде, «как есть», и предприятия самостоятельно устанавливали и внедряли ее в требуемом объеме. Все обновления программы, а их за почти 30 лет было не мало, проводились на предприятиях за 1 час собственными силами без привлечения услуг программистов. Потребности в перезагрузке сервера не возникает до тех пор пока вы не решили заменить его. Благодаря использованию для хранения и доступа к данным самой быстрой и надежной безтранзакционной СУБД Locis собственной разработки наши клиенты не получили ни одного разрушительного сбоя базы данных за 30 лет! В это трудно поверить, но это так!