– Расскажи ты мне, как мы с тобой на прошлой неделе рыли погреб …
(А. и Б. Стругацкие «Улитка на склоне»)
Хитры вы, конечно, суки легавые, с подходцами вашими.
(А. и Г. Вайнеры «Эра милосердия»)
Настала пора поговорить немного о вещах сугубо профессиональных: какие языки, базы данных и среды мы выбирали для своих приложений. Как мы это делали. Какие принципы и подходы закладывали в основу разрабатываемых систем. И какие вообще взгляды существуют на эти самые подходы.
Когда мы только начинали создавать первые программы под DOS, году эдак в 1989 – 1990 (еще до создания компании, работая через те самые ЦНТТМ, о которых я рассказывал в начале книги), естественным образом стал вопрос, какую выбрать базу данных для хранения бухгалтерской информации. Тогда было модно выбирать довольно экзотические варианты: R-Base, DB Vista, SyBase… То есть, конечно, такие варианты выбирали немногие из многочисленных компаний, творческих коллективов и фирмочек, выходивших тогда на рынок. Но именно они выглядели самыми продвинутыми, крутыми, и, ergo, модными. А такой имидж – тоже ведь далеко не самый маловажный маркетинговый фактор.
Но мы, рассмотрев и некоторые из экзотических вариантов, решили, что, напротив, возьмем самый распространенный формат, которым на тот момент, вне всякого сомнения, являлся DBF. Причины были очевидны: во-первых, работая с этим форматом, мы могли выбрать средство программирования (в дальнейшем для простоты я буду называть его «язык»), а не оказаться в заложниках у единственного и неповторимого проектировщика базы данных. Вторая причина вытекает из первой: на момент выбора уже существовало множество утилит для работы с данными в этом формате.
При выборе мы пренебрегли общеизвестным фактом низкой компактности DBF: объемы данных наших тогдашних потенциальных клиентов были не настолько велики, чтобы на этом зацикливаться. Зато нас привлекла весьма приличная надежность, доказанная как раз широким распространением данного формата.
Может быть, если бы мы изначально были нацелены на использование клиент-серверной технологии, в тот момент уже существовавшей, но недостаточно распропагандированной, решение было бы другим. Но у большинства наших клиентов и сети-то не было, а объемы данных, как я уже писал, были не столь велики, чтобы клиент-сервер стал актуальным. Файл-сервера более чем хватало.
Несмотря на упомянутую низкую распространенность локальных сетей, мы почти с самого начала закладывали в свои программы возможность сетевой эксплуатации. Но этот фактор обусловил и дублирование основных преимуществ сетевого использования встраиваемым в программы функционалом экспорта/ импорта данных с помощью такого давно канувшего в лету носителя, как дискеты..
После выбора формата нужно было понять, какой язык программирования мы будем использовать. Естественным образом, в первую голову мы попробовали Dbase, творение самих разработчиков DBF-формата. Уже не помню, что нам не понравилось в этом произведении программистского искусства. Скорее всего, интерфейс среды разработки. Рассматривали и более современный вариант, основанный на использовании DBF, FoxPro. Лучше, но тоже «не айс» (хотя, как я писал в предыдущей главе, в одном случае нам пришлось смириться с «лисичкой»). В результате был выбран Clipper. Среда разработки для этого языка так и не была создана, исходник надо было набирать в текстовом редакторе. Но это старым программистам, начинавшим свою карьеру еще с машинных кодов, казалось скорее преимуществом, чем недостатком. А вот то, что по уверению разработчиков языка, являвшегося более совершенной версией Dbase-синтаксиса, написанные на нем программы компилировались, а не интерпретировались, нас весьма обрадовало, ибо обещало выигрыш в быстродействии. Впоследствии мы поняли, что это утверждение являлось правдой лишь отчасти: в исполняемый файл добавлялся код, занимавшийся интерпретацией целого ряда языковых конструкций. То есть транслятор Clipper’а был компилятором лишь наполовину, максимум процентов на 70. Но в любом случае быстродействие программы оказалось немного выше, чем у языковых конкурентов. Пустячок, а приятно! Но главным аргументом в пользу Clipper’а стали, самым банальным образом, собственно возможности языка: работа с объектами (объектно-ориентированным его назвать никак нельзя, разве что только «частично объектно-ориентированным» ;), богатая библиотека встроенных функций, уже упомянутое подключение интерпретатора для отдельных участков кода, весьма обогащающее программистские «эротические фантазии»…
Я полюбил Clipper! За свою программистскую практику я разрабатывал программы не на слишком-то многих языках: машинные коды и ассемблер М-222, Алгол, PL-1, C, Clipper и PHP, – весьма короткий перечень. Но зато ревизовал чужие тексты (и исправлял в них ошибки – а для чего еще нужна ревизия?) большого лингвистического разнообразия, созданные совершенно незнакомыми мне средствами (в этом деле нужны, скорее, не знания, а логика). Тут и Фортран, и ассемблер ЕС, не говоря уже о более мне понятных FoxPro и C++… Всего не упомнишь! Так вот, моим безусловным фаворитом все эти долгие годы остается PL-1, язык весьма неэффективный, но за счет безграничного удобства и огромного числа альтернативных возможностей, вплоть до реализованных средствами языка стеков второго и первого рода (LIFO и FIFO). Признаться, я был очень расстроен, когда перейдя с мэйнфрейма на персональные компьютеры после продолжительных поисков наконец наткнулся на «персональный» компилятор PL-1 и понял, что вряд ли этот язык будет развиваться до первоначального варианта (впоследствии мои опасения подтвердились). А Clipper занимает в списке моих предпочтений уверенное второе место, с годами приблизившись к PL-1 на расстояние в несколько сантиметров.
Когда речь году примерно в 1995-м зашла о переходе под операционную систему Windows (следует признать, что такое значительное опоздание – сугубо моя вина: в силу природного консерватизма и несовершенства ОС Window-3.0 я считал, что DOS еще долго будет на коне), мы сначала надеялись на дешевый переход от DOS-приложений и попытались перетранслировать пару своих модулей с помощью вышедшей уже тогда версии Clipper для Windows, сделав незначительные правки в исходном тексте. Номер не прошел. Тогда было решено использовать в дальнейшем достаточно знакомый нам FoxPro, версия которого для новой ОС была куда как совершенней. Уже было понятно, что писать придется все заново. И поскольку, как я уже говорил, в тот момент мы ориентировались на рынок малых предприятий, нашему программисту Юрию Бармину была поручена разработка на FoxPro небольшой программы, включавшей бухгалтерские, складские и зарплатные функции. Получился довольно симпатичный продукт, который был назван «КОМПАС для Windows». Но, тем не менее, он был продан не больше пары десятков раз.
В первую очередь, в этом была виновата недостаточная «раскрутка». А нежелание вкладывать средства в эту самую раскрутку было вызвано тем, что пока писалась и отлаживалась программа на FoxPro, потихоньку в недрах компании стало набирать силу мнение, что если уж нам так или иначе придется переписывать все и вся, то надо извлечь из этого все возможные плюсы и попутно перейти на более современную клиент-серверную технологию в сочетании со все более популярными SQL-серверами. Как только в 1998-м году вышла в свет первая, еще весьма ограниченная и несовершенная версия нашей ERP-системы (в то время называть ее так было бы насмешкой), FoxPro’шная программа была снята с продажи и передана в бесплатное распространение с официального сайта компании, внеся свой вклад в повышение его посещаемости.
В результате торжества клиент-серверных настроений в 1996-м году «КОМПАС» пополнился тремя программистами, разрабатывавшими инструментальную часть будущей системы. Из этих трех программистов упоминания заслуживает только Леонид Рудый, страшный интроверт и отличный программист, впоследствии сделавший неплохую карьеру в каких-то западных компаниях. Львиная доля кода инструментальной части ERP-системы «КОМПАС» даже сегодня, после огромного числа внесенных туда усовершенствований и дополнений, принадлежит ему. Поэтому, хоть он и не внес ни строчки вклада в проблемную часть системы, Леню следует считать основным ее отцом ;.
Для программирования был выбран язык C++, просто потому что за него единогласно проголосовали программисты, причем не только занятые в проекте. А вот что касается базы данных, то тут решение было куда как более оригинальное. Все запросы, написанные на языке SQL, в том числе обращения к хранимым процедурам, выносились из исходного текста в отдельный слой, откорректировав который, можно будет настроить программу на любой SQL-сервер. В первоначальных замыслах было продавать версии для SyBase, Progress и даже Postgress. Но в итоге по разным причинам все ограничилось работой с двумя SQL-серверами: .MS SQL (для клиентов среднего достатка со сравнительно небольшим объемом данных) и Oracle (для тех, кто побогаче и покрупнее). Однако, в истории нашей компании имеется и практическое подтверждение правильности первоначальной идеи. Когда появился «жирный» потенциальный клиент, настаивавший на использовании InterBase и только InterBase, слой запросов бы адаптирован к этому серверу энтузиастом Borland Сергеем Когтевым за считанные дни. Недолгое время InterBase-версия поддерживалась наравне с основными, но когда мы поняли, что спроса на нее нет, а первоначальный клиент давно «сорвался с крючка», поддержка прекратилась.
Следующий переход с выбором средств программирования проходил уже без меня. Дело в том, что меня уже тошнило от программирования, я устал скакать по «языкам и весям» и, пользуясь своим привилегированным положением, решил, что буду участвовать в новом проекте разве что постановкой задач (да и то не слишком активно). Работать же буду на сопровождении DOS-проекта (аргумент: кто-то должен), все больше переключаясь на проблемы маркетинга, написание статей, сопровождение сайта и т.п. Когда во второй половине нулевых DOS-пакеты были сняты с сопровождения, это переключение стало окончательным и бесповоротным. Мой любимый напарник Никита Берсенев еще некоторое время помогал мне в этом сопровождении, но примерно с 1997-го года, когда дело дошло до создания проблемной части системы, все больше стал «откочевывать» на C++. Сейчас Никита является основным (среди многих) автором ERP-системы «КОМПАС».
Так что, когда году в 2001-м речь зашла о необходимости очередного шага по развитию нашего ПО, я оставался весьма отдаленным наблюдателем. Могу сказать только, что против того, чтобы сделать основой нового софта технологию .Net, не было подано ни одного голоса. Гораздо больше споров вызвал выбор языка программирования. Рассматривались и Basic, и Java… Но безусловным большинством голосов победил C#, на котором и была разработана TNP-платформа, переданная на бета-тестирование в 2010-м году.
Разрабатывалась она долго и, как говорится, не «за один присест». Сначала группу разработчиков возглавил мой старший сын Илья, вернувшийся из США после трех лет работы в Нью-Йоркских софтверных фирмах. Илья закончил матмех СПбГУ как раз тогда, когда я занимался вербовкой программистов для отправки их в Америку. Над ним нависла армейская угроза, и его мать предложила устранить ее путем отправки ребенка за океан. Идея была отличная! И хотя Илья с его нулевым практическим опытом явно не соответствовал критериям отбора заокеанских резидентов, я оговорил его включение в отбывающую команду в качестве бонуса к своей оплате. Как бы сам ребенок ни оценивал эту историю, его «командировка» оказалась более чем полезной и до сих пор американские пункты его резюме производят весьма благоприятное впечатление на потенциальных работодателей. Да и настоящим профессионалом (не по бумагам, а на деле) он стал именно в Америке. Сгубили его американскую карьеру два противоречивых обстоятельства: ссоры с чрезвычайно эмоциональной, но горячо любимой подругой и скука. Кроме того, он с его упрямым характером так и не адаптировался к американской политкорректности. Так на последнем из американских мест его работы были предъявлены три претензии. Во-первых, во время еженедельных meetings (совещаний) с русскими программистами разговаривает по-русски. Во-вторых, имеет обыкновение вносить предложения по улучшению работы компании, тем самым намекая, что не все в ней идеально. А самое страшное, на вопрос: «How are you? (как дела?)», – чаще всего отвечает: «Awful (ужасно)» ;. Но ссоры с подругой были все же важнее всего.
Вернувшись, он работал в питерской фирме, занимавшейся «офшорным программированием», а когда речь зашла о проекте под .Net, Нина перетащила его в «КОМПАС».
Группа Ильи делала пилотный проект. В 2004-м году он ушел (о причинах ухода я расскажу в одной из следующих глав), и группу возглавил работавший с Ильей Артем Букаев, который руководил ей еще год и тоже ушел, после чего группа распалась, а проект был заморожен. Прошло несколько лет, и возобновленные работы возглавили Олег Медведев и Сергей Когтев, замечательные профессионалы и носители хорошо известной на западе «российско-программистской профессиональной идеологии», выражающейся в лозунге (произносится всегда, без исключений, при столкновении с кодом, написанным другим, пусть даже самым лучшим программистом): «Все выбросить и написать заново». В соответствии с этим лозунгом они и поступили. Из кода пилотного проекта в TNP-платформе были использованы разве что жалкие крохи. При такой истории проекта не удивительно, что время его реализации оказалось впятеро больше прогнозируемого, если считать от начальной точки в 2001-м году.
По нашим замыслам планировалось перевести на TNP-платформу всю функциональность. На практике же до этого дело до сих пор не дошло. На этой платформе реализуются либо конкретные заказы, либо принципиально новые функциональные модули, которых не было в ERP-системе. Пример – модуль «КОМПАС: Путевые листы и ГСМ».
В общем, очередное подтверждение стандартной ситуации: на стартапе все делается быстро, а с одеревенением компании все процессы замедляются. Полная аналогия с человеческой жизнью: в детстве один день, как целая жизнь, а в старости десять лет назад, как позавчерашний день.
Вот, пожалуй, и все основные моменты истории нашей компании, связанные с решением «лингвистических» и «базовых» проблем. Теперь поговорим о двух противоположных подходах к проектированию и продвижению учетных и ERP-систем.
Кратко этот «конфликт» можно обозначить как «жесткость против гибкости». Разработчики жестких систем полагают, что в поставляемых ими программных продуктах учетные принципы, структуры данных, алгоритмы их обработки и т.п. должны быть «прошиты» недоступным для изменения образом, в предельном случае на уровне программного кода. Такой продукт, как полагает мой любимый адепт жесткого подхода Сергей Проскурин, может нести даже некие обучающие функции, предлагая пользователю, помимо всех приятных эффектов автоматизации, самые современные методы управления предприятием, с которыми до начала его эксплуатации он, возможно, даже не был знаком.
Сторонники же гибкого подхода считают, что пользователь должен иметь как можно более широкие возможности по настройке работы ПО на самые разные методы учета и управления предприятием, в том числе на разработанные им самим «ноу-хау». Демократия!
На самом-то деле, надо признать, что конечный пользователь: менеджер, плановик, бухгалтер, учетчик и т.д., – всегда использует именно жесткий продукт, пусть даже изготовленный путем настройки гибкой системы. Рядовой сотрудник и в отсутствие автоматизации управления предприятием должен действовать исключительно по установленным стандартам и правилам, проявляя свою инициативу в весьма ограниченных пределах, которые вполне доступны и при использовании жестких систем.
Так что различия между упомянутыми подходами заключаются, скорее, не в разнице во взглядах на то, что должен иметь конечный пользователь, а в распределении работ между этапами проектирования продукта и его внедрения, в наборе исполнителей, осуществляющих адаптацию системы к нуждам конкретного предприятия.
Жесткие системы практически полностью формируются на этапе разработки (иначе – проектирования). Во внедрении они не нуждаются (если не считать внедрением заполнение основных справочников, которое, впрочем, можно делать и по ходу эксплуатации). ИТ-специалисты Заказчика чаще всего самостоятельно устанавливают их на свои компьютеры, и тут же конечные пользователи приступают к работе, в соответствии с идеально точным и подробным Руководством по эксплуатации.
Гибкие системы предполагают достаточно длительный этап внедрения, включающий обследование бизнес-процессов автоматизированного предприятия (если оно не было проведено до приобретения софта).
Соответственно происходит и оплата работ. Жесткие системы полностью оплачиваются при приобретении. В случае гибких систем сначала идет оплата лицензий, а оплата внедрения осуществляется отдельно, либо после его завершения, либо поэтапно, в соответствии с договором. Случаи стопроцентной предоплаты внедрения чрезвычайно редки, в том числе и потому, что не всегда удается заранее обговорить полное содержание работ. Очень часто Заказчик на этом этапе вспоминает неучтенные при составлении договора тонкости и пожелания. Не реже наблюдение за ходом внедрения порождает «эротические фантазии», от которых его не удается отговорить. Все это – предмет дополнительных соглашений и дополнительной оплаты.
Вышесказанное вовсе не означает, что жесткие системы дешевле гибких. Напротив, гибкие системы и задуманы, в первую очередь, для того, чтобы переложить часть работ на специалистов по внедрению, зарплата которых, в общем и целом, ниже, чем у программистов той же компании. Гибкость – прием для удешевления конечного продукта. А встречаются и случаи, когда ИТ-специалисты Заказчика полностью берут внедрение на себя (один из примеров полной самостоятельности – АО «Псковэнерго», приобретшее в общей сложности 250 лицензий на различные входящие в ERP-систему «КОМПАС» модули). Дополнительное удешевление внедрения гибких систем достигается еще и тем, что в процессе своего существования они приближаются к жестким за счет создания так называемых отраслевых решений или шаблонов. Практически (без маркетинговых славословий) это означает, что за основу проекта для какого-то конкретного предприятия берется комплект настроек, являющийся результатом предыдущего внедрения в той же отрасли. Понятно, что такой подход снижает сроки реализации проекта и, соответственно, его стоимость. Если же в процессе эксплуатации продукта возникает потребность в каких-то индивидуальных адаптациях, то в жестких системах они в среднем обходятся клиенту дороже: по все той же причине разницы в зарплатах программистов и внедренцев. Подводя итоги, должен честно сказать, что общая стоимость владения продуктом (Total Cost of Ownership, TCO) не очень-то коррелирует с его гибкостью / жесткостью. Определяющее влияние на количество требуемых денег оказывают другие факторы: положение компании на рынке, динамика ее позиции (ведет ли она политику активного вытеснения конкурентов), географическое положение офисов, левая нога основного владельца…
Зато точно могу утверждать, что жесткие системы разрабатывают смелые, уверенные в себе и не слишком амбициозные люди. Почему? Да потому что такие системы рассчитаны на клиентов строго определенного профиля. Жесткую систему, предназначенную для использования в торговле, очень трудно применить, к примеру, в сталелитейном производстве, если только она не реализует исключительно самые общие бухгалтерские функции. Но чисто бухгалтерские системы сейчас мало кому интересны. Вот и получается, что разработчики жестких систем уверены, что на их век хватит выбранного ими сектора рынка, а «завоевывать вселенную» не входит в их планы, они удовлетворены своим куском хлеба с маслом.
В противоположность «жесткачам» разработчики гибких систем – это либо трусы, либо жадины (или вежливее, амбициозные люди), поскольку такие продукты распространяются куда как шире и таки годятся «для завоевания вселенной», Ну а если такое завоевание не входит в их планы, значит, они просто боятся оставаться на одном секторе рынка. Это трусы, к которым без сомнения относится наш «КОМПАС», утративший в какой-то момент своего развития глобальные амбиции.
В «начале большого пути» амбиции руководства «КОМПАСа» носили глобальный характер. Поэтому уже «КОМПАС КОМФОРТ» и «КОМПАС ГИГАНТ» были, скорее, гибкими продуктами, чем жесткими. Помимо возможностей параметризации (такой уровень настраиваемости характерен и для жестких систем), они включали в себя интерпретатор ЯФПК (языка формул и форм пакета «КОМПАС»). Это позволяло пользователю самостоятельно создавать новые печатные формы и подключать расчетные алгоритмы, изначально не предусмотренные разработчиками. Пользователь также мог самостоятельно настроить алгоритмы импорта данных из программных продуктов сторонней разработки, о чем я уже упоминал в предыдущей главе. Но структуры данных оставались жесткими и, хотя и не маскировались от клиентов, как это было сделано, например, в «1С», но и не описывались подробно. Визуальные формы представления информации также были прописаны жестко в исходном коде.
Когда речь зашла о разработке пакета «КОМПАС + SQL» (в будущем ERP-системы «КОМПАС»), Нина Якобсон стала активно (и даже агрессивно) продвигать идею полной настраиваемости. Ей очень хотелось как можно больше работ вынести на этап внедрения. С одной стороны, как я писал выше, это снижало общую стоимость владения продуктом, что повышало его конкурентоспособность, с другой, давало ей лично возможность отвечать на подавляющее количество вопросов потенциальных клиентов: «Да, в процессе внедрения мы сможем это реализовать» (помните про амбициозность, сиречь жадность? ;).
Короче, то, что в состав ERP-системы «КОМПАС» входит такой замечательный настроечный инструмент как «Мастера КОМПАСа», в первую очередь, Нинина заслуга. Нет, конечно, я не преуменьшаю вклада непосредственных разработчиков: Леонида Рудого, Никиты Берсенева, Сергея Когтева, Олега Медведева, Олега Хрусталева, Антона Горбатова, – но если бы не Нинина настойчивость, «Мастера» бы предоставляли пользователям куда как меньше привлекательных возможностей.
Сохранив и преумножив все настроечные возможности DOS-овских продуктов нашей компании, Windows-версия позволила пользователю менять структуры данных, добавляя новые поля к существующим таблицам и новые таблицы к базе данных в целом, корректировать существующие и создавать новые формы не только печатного, но и визуального представления и редактирования информации, как в виде таблицы (BROWSE), так и в виде полноэкранной визуализации одной записи или набора отобранных записей. Эта версия дала возможность самостоятельно настраивать критерии фильтрации и поиска данных, а также алгоритмы подсчета контрольных сумм. В ней можно менять вид пользовательского меню, подбрасывать новые иконки на панель инструментов, редактировать отчеты и т.д, и т.п.
Но главное то, что все эти настройки выполняются визуальными средствами, не требуя от настройщика квалификации программиста. А надо заметить, что чем большую часть необходимых настроек можно выполнить визуальными средствами, тем меньше сроки внедрения и адаптаций. Тем ниже, соответственно, их стоимость для клиента, который, к тому же, может значительную их часть взять на себя.
Но «Мастера», не ограничиваясь «визуалкой», предоставляют простор и для деятельности профессиональных программеров.
Во-первых, существует «Мастер запросов». Как я уже писал, SQL-запросы вынесены в отдельный слой, который редактируется именно этим «Мастером». Это, как было сказано выше, позволяет разработчикам переносить софт на новые SQL-сервера. А ИТ-специалисты клиентов «употребляют» его при создании собственных расчетных процедур, а также для оптимизации существующих запросов (никто не идеален, в том числе и программисты нашей компании ;).
Во-вторых, венчает список «Мастеров» «Мастер бизнес-процедур». Это интерпретатор встроенного языка класса Basic. Его активно используют и программисты производственного отдела, чтобы пополнять функционал, не меняя исходный код, и ИТ-специалисты пользователей – для подключения не предусмотренных нашей компанией функций. Язык этот достаточно прост – в «КОМПАСе» им владеют не только сотрудники производственного отдела, но и внедренцы.
Согласно статистике реализованных нашей компанией проектов, около 70% необходимых настроек и адаптаций реализуются визуальными средствами, 25% – на «Мастерах» для программистов, и только около 5% требуют вмешательства в исходный код программ. Ясен пень, это позитивно сказывается на сроках внедрения. В первую очередь, именно поэтому и возникла разница между проектами SAP и «КОМПАСа» на «Туламашзаводе», который я упоминал в предыдущей главе.
Как я уже писал выше, конечный пользователь всегда работает на как бы жесткой системе. Ему такие богатые настроечные возможности не только не нужны, но и просто опасны – не дай Бог случайно напортачит! Поэтому пришлось ввести в ERP-систему «КОМПАС» разграничение уровней доступа: рядовой юзер не имеет права пользоваться «Мастерами».
Но есть еще одно преимущество жестких продуктов перед гибкими, это простота обновления, перехода на новые версии. Жесткие системы всегда без проблем обновляются автоматически. При обновлении же гибких систем надо уметь сохранять изменения, сделанные пользователем, что не просто. Именно поэтому так много народу жалуется на процесс обновления «1С».
Нам же удалось решить эту проблему. Пусть не так радикально, как в «жестком» случае, но все же время обновления удалось резко снизить за счет создания удобной специализированной утилиты. А в версии 12.86, в которой все настройки автоматически делятся на 3 уровня: разработчика, внедренца и пользователя, - степень автоматизации обновления стала еще выше.
Я хотел бы написать, что «Мастера КОМПАСа» – уникальный инструмент. Но это, увы, не так! Он был уникальным несколько лет после того, как появился на рынке. Но с тех пор утекло много воды, а конкуренты не дремлют. «Мастера» явились предметом изучения и подражания. Я видел настроечный функционал «1С», «Альфы» и нескольких других фирм, созданный явно по образцу Компасовского. Добавлены кое-какие привлекательные черты, которых в ERP-системе «КОМПАС» не было, и нет. Но осмелюсь утверждать, что интегрально, по сумме возможностей и общему удобству, наши «Мастера» по-прежнему на первом месте. Возможно, я пристрастен, но все же, все же…
Шли годы. Компания взрослела. Мы все старели. Со старостью пришла то ли мудрость, то ли безразличие. Не выдержав конкуренции с безразличием, амбициозность позорно бежала в дальние края. Но трусость живет в нас и поныне. Мы по-прежнему боимся упустить хоть одного потенциального клиента, и по-прежнему (а может, и просто в силу сложившихся традиций) гибкость – это наш путь. Поэтому при проектировании TNP-платформы были заложены значительно более широкие возможности настройки по сравнению даже с ERP-системой. Собственно говоря, не просто так в названии появилось слово платформа – это инструмент для создания принципиально новых приложений . К сожалению, визуальная часть по сравнению с «Мастерами КОМПАСа» усовершенствовалась не слишком значительно. Основной упор был сделан на развитие программистской половины инструмента. Что ж, видимо, таково веяние эпохи. А может, тогда, почти 20 лет назад, мы просто слишком приблизились к пределу визуальных возможностей? Кто знает!
В дополнение к этому длинному пассажу о гибких и жестких системах хочу сказать о той области управления предприятием, которую я ни одному клиенту не посоветую автоматизировать на основе жесткого софта. Это CRM (управление взаимоотношениями с клиентами). Дело в том, что эта часть управленческого софта в наибольшей степени должна учитывать разработанные на предприятии бизнес-стратегии, с помощью которых менеджмент пытается получить конкурентные преимущества. Именно здесь нужно отражать изощренные «ноу-хау» руководства компании. То есть все очень индивидуально, а посему тиражную версию всегда надо перенастраивать. Да и изменения по тем же причинам в CRM вносятся куда чаще, чем в остальные части ERP. Так что «летайте самолетами Аэрофлота»! ((с)) Приобретайте гибкие CRM-системы.
На сем покончим с темами профессиональными и поговорим о вещах, куда более приятных :-))).