Постановка целей и задач технологии

Сегодня пользователи деловых компьютерных программ исчисляются, наверное, сотнями тысяч. Как бы ни были хороши компьютеры и программы, среди такого количества людей всегда найдутся недовольные результатами автоматизации. Для рынка в целом процент неудачных проектов не столь велик. Но для каждого конкретного потребителя неудача порой оборачивается большими проблемами. Отметим, что и для поставщика программ неудачные проекты несут дополнительные хлопоты и подрывают репутацию. Проблемы и конфликты в ходе автоматизации никому не нужны. Так почему же они возникают? Анализ критических ситуаций показывает, что почти всегда виноваты не программы или компьютеры, а люди. Намного легче исправить программу, чем изменить точку зрения человека. К моменту конфликта в проект уже вложена уйма денег. Закрыть проект - значит, выбросить затраченные средства и силы на ветер. Но и дальше так продолжаться не может. К нам нередко обращаются по поводу экспертизы программы или проекта. Чаще всего с помощью экспертного заключения люди надеются доказать вину противоположной стороны. Но на самом деле, поиск виновных не разрешает проблему. Лучше всего, чтобы проблемы не возникало вовсе. Для этого очень важно уметь взглянуть на проект глазами другой стороны. Попробуем это сделать вместе. Сразу оговоримся, что случай действительно слабых и недоделанных программ мы здесь не рассматриваем. Многие потенциальные проблемы закладываются еще на этапе выбора программы или фирмы-разработчика. Приведем типичный пример. Тиражные недорогие бухгалтерские или торговые программы, имеющие наибольшую известность, рассчитаны, как правило, на небольшие и в отдельных случаях на средние предприятия. Их распространением занимаются дилеры. Такие программы всегда дешевые, иначе они не были бы массовыми. Доход от простой продажи таких программ невелик. Поэтому дилеры стараются заработать на услугах по внедрению и настройке, для чего они заключают контракт на комплексную автоматизацию. Сумма контракта обычно пропорциональна величине предприятия, и некоторые дилеры стараются заполучить клиента покрупнее - завод или даже холдинг. Но, как мы помним, программа-то рассчитана совсем на другой размер предприятия. В результате закладывается мина замедленного действия. Проблемы возникнут не сразу, а по мере ввода в эксплуатацию все новых и новых рабочих мест. Система начнет работать с непозволительными задержками. Возникнут проблемы с получением сводных результатов, с разграничением полномочий, со спецификой учета на отдельных участках и т.д. Как ни странно, но претензии заказчика могут возникнуть не к дилеру, а к разработчику и к его "плохой" программе. Но разработчик честно предупреждал в рекламе, в документации и даже в надписи на коробке, что программа ориентирована на такой-то размер и такой-то профиль деятельности предприятия. С точки зрения разработчика, виноват дилер и сам клиент. В нашей практике встречались случаи, когда корпорация ломала голову, что лучше выбрать систему R/3 или купить много программ "1С: Бухгалтерия". В первом случае проект обойдется в миллион долларов. Во втором - затраты уменьшатся на несколько порядков, а программы фирмы "1С" известны своим высоким качеством. Мы не утверждаем, что крупному предприятию всякий раз нужно покупать R/3 или "Галактику". Но выделяемые средства и рассматриваемые программы должны быть сопоставимы с масштабом поставленных задач. К числу ошибок клиента можно отнести также неуместную экономию на внедрении, настройке, обучении. Дорогостоящие программы внедряются собственными силами на протяжении долгих месяцев и в результате работают лишь на 5-10% своих возможностей. Зачастую подводит желание быть полностью независимым от разработчика. Для этого приобретаются самые гибкие программы, чтобы можно было самостоятельно настроиться на любые изменения в законодательстве. Но ирония состоит в том, что для такой настройки привлекаются случайные программисты, зависимость от которых еще хуже, чем от разработчика или официального дилера. Предположим, что выбор сделан. Выбрана и установлена достойная программа. При этом контракт предусматривает обучение, но к началу опытной эксплуатации персонал заказчика понятия не имеет, как работать с системой. Директор и главный бухгалтер сами программу не выбирали, но они были в курсе, что на проект затрачены немалые деньги. Они почти поверили в то, что автоматизация - это не модное веяние, а приносящее результат дело. Вдруг оказывается, что компьютеры и программы стоят сами по себе, а персонал работает по старинке. С точки зрения этих руководителей, во всем виноваты разработчики. Им заплачены деньги, а результата нет. По мнению разработчиков, виноват заказчик, который не только не смог организовать процесс обучения, но и вообще не желал прилагать никаких организационных усилий. Переход на компьютерный учет для крупного и даже среднего предприятия - это очень непростой процесс, требующий пересмотра буквально всех привычных операций, проведения ревизии всех документов, сверхурочной работы персонала, двойной нагрузки от параллельного ведения ручного и компьютерного учета. Без железной воли руководства такой процесс не может быть проведен в сжатые сроки. А растягивание этого процесса во времени может отбить желание к автоматизации у любого сотрудника. Каждое достаточно крупное предприятие по-своему уникально. Начиная от способа распределения учетных функций между персоналом и заканчивая тем, как территориально расположены рабочие места с компьютерами и каким образом они соединены в сеть. Автоматизация зачастую ведется поэтапно и в целях экономии предварительное полномасштабное обследование не проводится. Поэтому через год - другой после начала работ вдруг выясняется, что производительность уже выбранной системы недостаточна. Прикладная разработка вполне хороша с точки зрения набора функций, но инструментальная платформа слабовата. Разработчик утверждает, что необходимо переходить на Oracle и докупить несколько более мощных компьютеров. Но заказчик не согласен нести дополнительные расходы. Таким образом, вновь возникает патовая ситуация. Предположим, что проект доведен до логического конца. Система установлена, доработана, персонал обучен. Но накануне сдачи проекта выясняется, что, по мнению заказчика, ряд задач решен не так. Исполнитель в свою очередь утверждает, что по результатам опытной эксплуатации эти задачи были признаны полностью соответствующими требованиям технического задания. В чем же дело? Просто само задание было составлено давно и его авторы уволились. Отдельные элементы комплекса вполне удовлетворяют отдельных пользователей. Но кто-то должен принять все в целом. Для этого заказчик срочно назначает нового ответственного, который совсем не в курсе дел. Ответственный в целях подстраховки начинает придумывать новые требования, чтобы оттянуть момент подписания акта приемки. Еще чаще нам приходилось сталкиваться с проблемами, возникающими по причине смены руководства. В этом случае почти всегда меняются цели, стратегия, а иногда даже и направление деятельности. Разработчики в это время заканчивают последний этап автоматизации и неожиданно обнаруживают, что результат их труда безнадежно устарел. Надо сказать, что чаще всего новое руководство в таких случаях не имеет претензий к разработчикам, но и доводить до конца проект тоже не соглашается. Нередко оно настаивает на установке иной программы, более знакомой им по месту предыдущей работы. Персонал предприятия, потративший полгода на освоение и запуск одной программы, естественно, не хочет еще полгода осваивать другую. Кстати, чем комплексным бывает внедрение программ, тем труднее ее заменить. На одном крупном пивном заводе долгое время внедряли отечественную разработку. Разработчики вместе с аудиторами выступали при этом еще и в роли консультантов по постановке учета и финансового планирования. Проект был удачно завершен. Но через полтора года завод был перекуплен иностранцами, которые настояли на покупке западной программы вместо российской. А еще через 10 месяцев тщетных усилий по ее внедрению вновь вернулись к отечественной разработке. Как объяснили нам аудиторы, весь учет и едва ли не все управленческие технологии на заводе были построены под ту первую российскую программу. Сменить программу было невозможно без смены всей технологии учета и управления. А западную программу не выбросили. Раз или два в году с ее помощью печатали некие справки для иностранных совладельцев. Мы привели лишь несколько примеров, обозначив в каждом случае причину возникновения проблемы и мнение каждой стороны. Разобравшись с причиной любой конфликт можно преодолеть. При одном условии - для этого должна быть добрая воля обеих сторон. Но в жизни, в отличие от статьи, каждый чаще видит только свою правоту. На прошедшем недавно собрании ведущих российских разработчиков деловых программ затрагивалась, в том числе и эта проблема. Мы рассказали о наших шагах по защите интересов потребителя и нейтрализации конфликтов. Фирмы со своей стороны изъявили готовность предпринять ряд мер по предотвращению потенциальных конфликтов. Например, одна из таких мер - обмен информацией о недобросовестных дилерах. Была затронута и роль прессы в просвещении потенциальных потребителей, в знакомстве их с существующими видами программных продуктов, в объяснении важности более серьезного и ответственного подхода к автоматизации.