Александр Кухтин Сокращенный вариант статьи опубликован в журнале "Компьютерное Обозрение" N 27, 2000 Серебряная пуля украинского предпринимателя: мифы и реальность Во времена седой древности существовало поверье, что оборотни неодолимы обычными для той эпохи способами. С появлением пороха и ружей неизбежно появилось и новое магическое средство против оборотней - серебряная пуля. В настоящее время на многие порядки возросшая сложность современного мира также потребовала появления “серебряной пули” для борьбы с информационным хаосом, то есть обеспечения адекватного управления огромными, возрастающими в геометрической прогрессии, массивами информации. Все вести с последнего экономического форума в Давосе только и пестрели сообщениями о переходе к экономике нового типа - экономике информационного века, основанной на компьютерных технологиях, используемых на любых уровнях управления. В какой степени это касается Украины, существует ли “серебряная пуля” украинского бизнеса и если существует, то как она «выглядит»? Начальные условия Следуя примеру древних геометров, примем без доказательств в качестве аксиом следующие положения: на фоне продолжающейся агонии крупных промышленных предприятий единственная надежда устойчивого экономического роста в Украине связана с работой сектора среднего и малого бизнеса; уровень использования компьютерных технологий для управления малыми и средними предприятиями в Украине весьма низок даже по сравнению с Россией; нет никаких оснований полагать, что внедрение автоматизированных систем управления предприятием (АСУП) дает эффект только на крупных предприятиях. Рост вычислительной мощности и одновременное снижение стоимости аппаратных средств позволяют говорить о доступности внедрения и эффективности АСУП даже для некоторых предприятий малого бизнеса. Очевидно, что у нас совершенно не развит финансовый учет и анализ, и причины этого коренятся не только и не столько в сильном фискальном давлении государства и “теневой” экономике, сколько в элементарной неосведомленности большинства руководителей предприятий. До сих пор в среде предпринимателей весьма распространено мнение, что автоматизация работы бухгалтерии заключается лишь в формировании фискальной отчетности, то есть чего-то неизбежного, но совершенно ненужного и даже вредного для предприятия. Задачи оперативного учета, например автоматизация работы склада, воспринимаются с большим пониманием, но как-то обособленно, без попытки интеграции разрозненных показателей, позволяющей анализировать развитие хозяйственной и коммерческой ситуации для минимизации потерь и получения максимальной прибыли. Все эти недостатки отечественного менеджмента существенно снижают КПД украинских предприятий, а, учитывая, что в малом и среднем бизнесе имеют реальный доход более половины трудоспособного населения Украины, становится очевидным, что, в конечном итоге, неумение наших предпринимателей обеспечивать оптимальное управление сказывается практически на каждой семье. В этой связи может возникнуть вопрос: может быть, превалирование мелкого и среднего бизнеса - это не более чем кратковременное явление, и все вернется к «гигантомании» прошлых лет? Безусловно, нет, так как в США на долю предприятий с численностью работников до 100 приходится более половины всего трудоспособного населения. И эта доля продолжает расти. Поэтому цель данной статьи - сформулировать хотя бы в самом общем виде требования к АСУП для средних и малых предприятий, которые будут поняты и восприняты значительной массой отечественных менеджеров, и представить объективную критику тех, на наш взгляд, опасных мифов и заблуждений, которыми в настоящее время пытаются подменить отечественную реальность. Мифы наших дней Суха теория, мой друг, а древо жизни пышно зеленеет. И. Гете. «Фауст». Мифы сопровождают человечество на протяжении всей истории. К сожалению, не свободна от мифов и сфера финансово-экономического программного обеспечения. По нашему мнению, здесь наиболее распространены следующие три мифа. Миф первый: достаточно купить программу класса SAP R/3, Baan или вообще любую финансово-экономическую программу, и все проблемы с автоматизацией учета будут решены. Даже не обсуждая чрезмерно высокую стоимость подобного решения, необходимо заметить, что: Западные разработки выросли на почве бизнеса, построенного на совершенно иных традициях и принципах. Наши программы должны вырасти вместе с нашим бизнесом. Все крупные западные системы рассчитаны на устоявшийся бизнес, на развитый рынок труда, на определенное отношение государства, на определенную работу с собственником (акционерами) фирмы. У нас же условия совершенно иные. Следует также заметить, что в западноевропейских странах малые и средние предприятия, в отличие от транснациональных гигантов, применяют для автоматизации бизнеса разработки отечественных программистов. Причины достаточно прозрачны - в каждой стране, несмотря на объединение в рамках Евросоюза, существуют свои особенности учета, и только транснациональные корпорации могут себе позволить работу по собственным схемам. Очевидно, что лишь местные разработчики могут обеспечить максимально быструю реакцию на изменения местного законодательства и соответствующую поддержку. Вывод авторов достаточно тривиален: чтобы разбираться во всех нюансах жизни общества (в том числе и экономической), нужно жить в этом обществе. Миф второй: при внедрении АСУП необходимо применять только классические методы проектирования. Одна из проблем украинского рынка финансово-экономических программ еще и в том, что сейчас отечественные фирмы, которые доросли до полной автоматизации (в том смысле, который вкладывается в это слово IT специалистами), можно пересчитать по пальцам. Все большие, реально работающие предприятия - это или СП с западным капиталом, или полностью иностранные. И их доля в общем количестве предприятий, согласитесь, мизерная. Еще одно наблюдение авторов, как практиков: часто в прессе пишут о том, что нужно все проектировать, а затем реализовывать. К сожалению, подобная схема часто не работает даже на Западе, а тем более у нас. Да и как это может работать, если составление сколько-нибудь серьезного проекта занимает в идеальном случае несколько месяцев, а реально может не уложиться и в год. За это время организация, для которой составляется проект, может полностью изменить свою структуру, ее доход может измениться в несколько раз, как в большую, так и в меньшую сторону. Поэтому наше мнение, как практиков, заключается в том, что сейчас необходимо не «учить всех мужиков французскому языку», а работать на сегодняшнем рынке и с сегодняшними клиентами. Нужно постепенно решать те проблемы, которые есть, зная о том, какими они станут в дальнейшем, а не заниматься «глобальным» проектированием всего и вся сразу. Вести разговоры о BPR, ФСА, CASE-проектировании и не иметь готовых, реально работающих в условиях нашей экономики, решений? Для отечественных предприятий подобные методики, по нашему мнению, пока представляют ценность, сравнимую с ценностью высшей математики для первоклассника. Например, в США только 30% проектов BPR успешно завершаются, причем практика показывает, что неготовность предприятия зависит от факторов корпоративной культуры, неоптимального руководства и несерьезного отношения работников. Миф третий: необходимо менять программы, как перчатки, по мере роста предприятия. Неоднократно приходилось слышать утверждение, что предприятие, меняя структуру, «вырастая», должно избавляться и от старой АСУП. Подобное мнение нам представляется устаревшим, совершенно несоответствующим интересам клиента и противоречащим современным тенденциям. Система должна иметь возможности роста и модификации, обеспечивающие адекватное реагирование на изменение структуры предприятия, и современные технологии обеспечивают такие возможности. Как отлить серебряную пулю? С середины 90-х годов “де-факто” принята следующая, довольно упрощенная, классификация финансово-управленческих программных инструментов для построения АСУП: мини-бухгалтерии (например, ранние версии 1С, Инфо-бухгалтер и др.) интегрированные программы и конструкторы (Финансы без проблем, Парус, X-DOOR, 1С, Акцент и др.) программы международного уровня (SAP R/3, Baan, Scala, и др.), а также приближающиеся к ним по сложности российские «Галактика» и «Парус-Корпорация». Следует подчеркнуть, что в ряде статей программы называются системами (видимо, для оправдания их цены), что, по нашему мнению, не совсем корректно, так как это не более чем наборы инструментов, с помощью которых на конкретном предприятии смогут (или не смогут, чему уже достаточно примеров) построить АСУП. Необходимо также отметить, что в последнее время между двумя последними категориями различия стираются. «Клиент-серверные» версии интегрированных программ и конструкторов успешно «перемалывают» всевозрастающие объемы учетных данных. Выводы из всего вышесказанного ясны: прошли те времена, когда отечественные разработки высокомерно называли «доморощенными». Отечественные программы наращивают мощь, сохраняя большинство своих достоинств, таких как наглядность, простота, гибкость. И это находит одобрение у пользователей. Например, данные опроса среди посетителей российской выставки “Бухгалтерский учет и аудит’99” показали, что пользователи финансово-экономических программ наглядность и простоту поставили на первое место. Этот критерий отметили 29% участников опроса, удобство работы - 27%, гибкость - 22%, надежность - 15%, стоимость - 7%. Все вышесказанное позволяет утверждать, что идеальная система управления должна быть чем-то вроде растущего организма. Проследим весь цикл развития предприятия и посмотрим, как должна выглядеть наша «серебряная пуля». 1. Малое предприятие имеет небольшие обороты, но директор и бухгалтер все равно не справляются с потоком бумаг и теряют конкретные деньги из-за того, что не успевают. Покупаем компьютер и недорогую бухгалтерскую программу ($100). Программа должна работать сразу и не требовать никаких настроек (не забываем, что мы в идеальном мире). Программа также должна быть максимально удобной, понятной и прозрачной. Никаких привязок к фирме-продавцу, никаких денег за сопровождение (сопровождение должно быть бесплатным в виде новых исправленных версий и линии «горячей поддержки»). 2. Фирма подросла, бухгалтеров стало несколько, появились операторы для набивки документов. Докупаем компьютеры, ставим одноранговую сеть и расширяем (а не заменяем!) программу. Теперь в нее входят полноценные средства разработки форм, отчетов, возможности менять интерфейс пользователя, управлять доступом персонала, отслеживать статистику работы и другие «полезности». Кто будет все это настраивать? Вариантов два. Первый: у вас есть свой человек, который разбирается во всем этом и готов (нужно бы ему повысить зарплату). Второй: поручить это специализированной фирме, которая занимается только этим. Как правило, это будет быстрее и дешевле. 3. Фирма выросла еще, число сотрудников увеличилось, данных слишком много, проблемы управления множатся. Докупаем еще компьютеры, покупаем выделенный сервер, нанимаем администратора сети/системы и переходим на версию клиент-сервер нашей гипотетической программы. Переход должен быть максимально прозрачным (как правило, если настройщик на втором этапе не использовал «хитрых» возможностей, такой переход должен быть полностью автоматическим). Некоторые подразделы учета/управления выносятся на отдельные рабочие места (покупаем нужные модули, которые просто более удобно обрабатывают имеющиеся данные и позволяют вводить дополнительные). На этом этапе появляется необходимость использовать средства анализа. Данных уже достаточно для прогнозирования и т.п. 4. Фирма еще подросла и начинает превращаться в корпорацию. Появились филиалы, объемы выросли многократно. Система должна стать распределенной. Более изощренное администрирование, более сложные алгоритмы. Появляется то, что называется финансовым анализом. Возможно ли построить такую систему? Вполне. Современные технологии позволяют реализовать супермасштабируемое решение. Как этого добиться? Условиями успеха являются, по нашему мнению: 1. Ориентация на наиболее массовые платформы. Наиболее реальный претендент – Windows. Хотя, безусловно, наличие альтернативных технологий еще никому не мешало, но ориентироваться сейчас на разработку бизнес-приложений под Unix, с нашей точки зрения, преждевременно. 2. Открытая архитектура базы данных (само собой разумеется, реляционная). Универсальная структура базы данных (БД) с возможностью расширения. Это ключевое место. Если структура БД общая для всех, то никакие наработки не пропадают. Возможен репозитарий решений, приемов работы, методов учета. Отсюда прямая дорога к автоматическому (почти) построению конфигураций. Например, торговля-учет по партиям - НДС, в том числе – валютный учет и прочая, прочая... Кстати, если общение с БД идет на уровне SQL и соблюдаются некоторые простые правила, то расширяемость БД получается практически бесплатно. Если для работы какого-то кусочка требуется расширить БД, это может делаться автоматически. 3. Универсальный, но расширяемый язык программирования настроек. Хороший кандидат, по нашему мнению, это Visual Basic Script. Универсальный, простой, очень гибкий, бесплатный, с отличной поддержкой от Microsoft, легкая расширяемость, огромная инсталлированная база, встроенность в Windows, MS Office, SQL-server, Internet Server, Explorer и прочая, прочая. Идеально расширяется с помощью ActiveX, позволяет управлять внешними приложениями/объектами. Его знает очень много людей. Кроме того, технология Active Scripting, позволяет достаточно просто заменить язык, к примеру, на JavaScript без изменения объектной модели приложения. Может быть, еще VBA – реальный претендент, но за него надо платить, он гораздо сложнее в освоении и самое главное: язык в системе нужен не для разработки приложений, а для «склейки» разных объектов в единое целое. VBA для этого “тяжеловат”. 4. Независимость от сервера БД. Если бы все разработчики СУБД поддерживали стандарты так, как это декларируется, было бы гораздо легче жить разработчикам приложений. А так должен быть выделен уровень трансляции бизнес-запросов в запросы к БД. Причем в легких вариантах этот уровень должен быть очень быстрым (скорее всего, просто DLL), а в тяжелых может быть отдельный сервер приложений и 3-x (и более) уровневая архитектура. 5. Расширяемость на двоичном уровне. Идеальное решение – ActiveX, универсальней с практической точки зрения просто некуда. Причем в приложении должна быть документированная возможность встраивать что-то типа AddIns, которые прозрачно интегрируются в пользовательский интерфейс. 6. Интеграция. Должна быть возможность работать с наиболее распространенными приложениями напрямую и сразу. Слава Богу, это обеспечивается OLE Automation и VBScript. Для унаследованных приложений должна быть возможность ими управлять, писать/читать данные в/из них и пр. Иногда это может потребовать дополнительного программирования. Кроме того, сами приложения тоже должны быть Automation-server, чтобы и ими можно было управлять снаружи. Дополнительно, хорошо бы иметь универсальный набор бизнес-объектов, оформленных как настоящие ActiveX. Если они есть, то можно использовать популярные среды типа Visual Basic, Delphi, для работы с этими объектами. Это будет гораздо удобнее специализированных конфигураторов типа 1С. 7. Распределенные БД и Интернет. Перевод всего в Internet Explorer, скорее всего, вреден. Работает медленно и никаких особых преимуществ не дает. Конкретного пользователя не интересует, что его приложение может работать и на других платформах тоже, а потери производительности очень существенны. Однако, было бы полезно иметь возможность посмотреть (через Интернет) финансовое состояние фирмы, состояние складов, выполнить какие-то операции администрирования. В конце концов, главбух может захотеть послать платеж, сидя на пляже, почему бы и нет. Но более интересен Интернет для конечных пользователей. Прайс-листы, возможность сделать заказ, проследить его прохождение и т.д. и т.п. Очень заманчиво. Еще одно применение – распределенные БД. Удаленные склады, филиалы и пр. Связь в стандартном формате (XML, BizTalk) и в перспективе полностью электронные взаимоотношения с поставщиками/потребителями. Все это возможно уже сейчас, разумеется, со скидкой на местные условия. В системе изначально должна быть заложена возможность расширения до такой степени. Различные «примочки» потом будут дорогими и неэффективными. Итоги Краткие выводы статьи: - развитие АСУП должно идти путем эволюционного развития, без резких скачков и колебаний; - программные инструменты АСУП должны иметь возможности роста и модификации, обеспечивающие адекватный ответ на запросы растущего и меняющего свою структуру предприятия; - реально работающие и эффективные АСУП для отечественного среднего и малого бизнеса, скорей всего, могут быть созданы лишь отечественными разработчиками. В заключение, следует подчеркнуть, что уровень развития компьютерных технологий уже сейчас позволяет создать близкую к идеальной систему управления.