Выбор системы без участия консультантов

В принципе при выборе автоматизированной системы совсем не обязательно участие консультантов. Нужно только взвешенно и трезво подходить к этому вопросу и заранее сформулировать для себя важные критерии. Основной критерий выбора системы — ее функциональная полнота. Система должна автоматизировать все основные операции учета на предприятии, а также, возможно, некоторые специфические операции, характерные для конкрет- ных типов предприятий (банков, торговых, страховых, посредни- ческих компаний, промышленных предприятий и т.д.). Большин- ство предлагаемых на российском рынке систем автоматизации имеют приемлемую функциональную полноту. При этом на пер- вый план выходят другие параметры оценки системы.

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

Правило 1. СИСТЕМА ДОЛЖНА БЫТЬ ПОНЯТНОЙ.

Важнейший критерий выбора системы — это возможность по- нимания принципов ее работы конкретным бухгалтером или дру- гим специалистом. Очевидно, что после изучения рекламного про- спекта или просмотра демонстрационной версии программы на условном примере фирмы-разработчика нельзя получить полное представление об ее возможностях. Необходимо вникнуть в систе- му, «почувствовать» ее.

Для достижения этой цели лучше всего попробовать начать работать с программой «с нуля» на своем собственном небольшом примере. Этот пример должен быть подготовлен заранее и в него следует включить все основные типы операций.

Очевидно, что солидная фирма-разработчик должна достаточ- но легко согласиться на подобное тестирование, а вот заявления типа «сначала купите, потом тестируйте» должны насторожить. Если автоматизация важнейших участков учета на собственном примере при помощи выбранной системы идет успешно и техноло- гия выполнения всех операций не вызывает трудностей, можно считать, что система в целом понятна пользователю.

Правило 2. СИСТЕМА ДОЛЖНА БЫТЬ УДОБНОЙ.

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

Выбираемая система может считаться удобной только тогда, когда она удобна для конкретного человека. Именно он определя- ет степень удобности той или иной автоматизированной системы и эта оценка должна быть решающей.

Так как все люди разные, то и оценки комфортности работы с той или иной системой у них неодинаковые. Одни (в первую оче- редь, пожилые и неискушенные пользователи) скорее всего выбе- рут простую и понятную систему, а сложную работу захотят сделать вручную. Другие (более молодые и уже знакомые с компьютером) предпочтут пусть и сложную в эксплуатации систему, зато с боль- шими функциональными возможностями. Не исключен и путь по- степенного усиления системы по мере роста компьютерной квали- фикации специалиста. Зато противопоказан обратный подход: «ку- пим сложную систему, а людей потом научим». Такое решение может привести к настоящей катастрофе, и виноват в этом будет не исполнитель, а тот начальник, который ему эту систему навязал.

Довольно распространен еще один неверный подход к автома- тизации на предприятиях: подбор персонала под систему. Часто можно встретить рекламу типа: « ... требуется специалист, умею- щий работать в системе ...». А как до приема на работу проверить реальные знания кандидата? Как узнать, будет ли данная система удобна в его работе? При поступлении на должность кандидат ска- жет что угодно, а дальше начнутся проблемы. Итак, система под- бирается под человека и должна быть удобна для него.

Правило 3. СИСТЕМА ДОЛЖНА БЫТЬ НАДЕЖНОЙ.

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

Во-первых, система должна отслеживать все виды случайных ошибок, нарушающих ведение учета. Например, абсолютно недо- пустима «полупроводка», когда сумма проводится по дебету одно- го счета и не отражается по кредиту другого. Или наоборот. Не должно быть разночтения курсов иностранных валют к рублю в течение одного дня и т.д.

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

Наконец, система должна быть устойчива к сбоям и поломке оборудования. Здесь возможны разные решения: автоматическое сохранение базы данных в процессе работы, обязательная выгруз- ка копии на дискеты или стример, специальные средства восста- новления данных. Важно, чтобы эти средства существовали и ра- ботали.

Оценку надежности системы, как и ее понятности, лучше все- го проводить при помощи собственного тестирования. Попросите разрешить вам самостоятельно поработать с системой и попробуй- те несколько раз «ошибиться». В зависимости от результатов тес- та можно сделать первые выводы о надежности системы. Не менее важно задать представителю фирмы-разработчика вопрос о на- дежности и попросить продемонстрировать реакцию системы на ошибку или сбой на примере (лучше подготовленном Вами). Отказ разработчиков от такой демонстрации позволит сделать необходи- мые выводы, а в случае согласия вы все увидите сами.

Правило 4. СИСТЕМА ДОЛЖНА БЫТЬ АДЕКВАТНОЙ.

Как уже отмечалось, переходная экономика характеризуется обилием изменений в правилах бухгалтерского учета и отчетнос- ти. В этих условиях приобретаемая автоматизированная система достаточно быстро может оказаться неадекватной текущему поло- жению дел. Возможны два пути решения этой проблемы.

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

Солидные компании заботятся о своих клиентах, что выража- ется в развитой системе скидок на замену версий (upgrade), свое- временной подготовке адаптированных руководств пользователя системы, обеспечении телефонных консультаций по «горячей ли- нии» и т.д. Слабые разработчики эти услуги обеспечить не могут, и их клиенты часто «зависают», так как не могут использовать уже неадекватную реальной жизни систему.

Второй путь предполагает настройку системы в соответствии текущими требованиями. Это означает, что система изначально разрабатывается как легко адаптируемая, мобильная и гибкая. Такой подход к разработке требует создания в системе определен- ной избыточности функциональных возможностей, что делает ее несколько более сложной при эксплуатации. Позитивным при та- ком методе внесения изменений в систему является отсутствие частой смены версий, а негативным — усложнение работы бухгал- тера с компьютером ввиду необходимости самостоятельной настройки системы.

Есть еще одно решение, смысл которого заключается в посто- янном или периодическом сопровождении системы со стороны работников фирмы-разработчика. Для этого в структуру постав- ляющей систему компании включаются выездные бригады кон- сультантов или создаются филиалы в наиболее важных регионах.

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

Правило 5. РАЗРАБОТЧИК ДОЛЖЕН БЫТЬ СОЛИДНЫМ.

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

— стаж работы фирмы на рынке;

— количество проданных копий или успешных случаев внедрения системы (всего и за последний год);

— цена системы (очень низкие и очень высокие цены одинаково опасны);

— наличие или отсутствие поддержки системы, виды поддер- жки («горячая линия», консультации в офисе фирмы, выез- дные консультации, собственные службы внедрения и т.д.);

— наличие или отсутствие учебных центров;

— отзывы пользователей, уже купивших эту систему;

— другая деятельность фирмы.

Используя перечисленные выше правила (а, может быть, свои собственные критерии оценки фирм-разработчиков и их программ- ных продуктов) можно самостоятельно выбирать систему автомати- зации. Как уже отмечалось, информацию по системам можно полу- чить на специализированных выставках и семинарах, презентаци- ях компаний, непосредственно при визите в компанию, поставляющую на рынок системы.