«Самописцам» на заметку

Раздел: Информационные технологии
Автор(ы): Сергей Зелинский, директор по маркетингу компании "АМИ-Украина" (журнал "IT-Менеджер")
Источник: Журнал "IT-Менеджер" (№3, 2004)
размещено: 01.07.2004
обращений: 10133

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

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

Встречаются предприятия, у которых нет никакого ПО для автоматизации определенной деятельности, но они интересуются доступным на рынке решением с одной лишь целью — воссоздать его собственными силами. Самый типичный разговор с такими клиентами выглядит следующим образом.

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

Вот те аргументы, которыми обосновываются самостоятельные разработки ПО отделами АСУ отечественных предприятий.

Писать или не писать

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

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

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

Очень часто поднимается вопрос интеграции ПО с системами, уже работающими на предприятии, в том числе и «самописными». Приемлемой степени интеграции можно добиться через экспорт/импорт данных. С помощью языка XML сегодня можно передать данные между любыми приложениями, в том числе и разработанными старым инструментарием.

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

Даже после создания программы на предприятии она может быть "своей" в полном смысле только для исполнителя. Заказчик в лице руководителя предприятия так и остается заказчиком. При увольнении исполнителя предприятие может навсегда потерять разработанную программу. Поэтому неудивительно, что за самостоятельную разработку всегда будет выступать исполнитель, как непосредственно заинтересованная сторона.

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

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

«Не сесть на иглу разработчика» — так часто аргументируют свое нежелание приобретать тиражное ПО. Но все как раз наоборот: известны много случаев, когда именно свои программисты «сажают на иглу», особенно становясь бывшими сотрудниками.

Многие предприятия, приступая к разработке собственного ПО, рассчитывают в последствии сделать его тиражируемым и зарабатывать на этом. Очень трудно удержаться на рынке, уже занятом конкурентами, у которых преимущество во времени и клиентах. Хотя есть и удачные примеры, но это исключения, которые, как известно, только подтверждают правила.

Покупать и как покупать

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

Как правило, на предприятии работа ведется с массивами данных, в которых хранятся сведения о товарах, сделках, сотрудниках, клиентах и т.д. Поэтому в программе должны присутствовать и поддерживаться хорошие поисковые механизмы. Для быстрого получения аналитических данных желательно иметь средства, позволяющие получать данные по контексту — «на лету».

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

DOS, Windows, Linux — или другая операционная система? На этот вопрос необходимо ответить так: приобретенная система должна соответствовать той, что используется в отделе или на предприятии в целом. Кроме того, важно уточнить, под управлением какой версии операционной системы можно работать, особенно это касается наиболее популярной среди отечественных пользователей Windows. Ведь различные версии Windows поддерживают собственные компоненты для управления данными. Также нужно уточнить, какие именно системы управления базами данных (SQL-серверы) поддерживаются, потому что если программа не работает в среде СУБД, используемой на предприятии, вам придется приобретать новый SQL-сервер.

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

Совершенно очевидно, что выбранная программа должна работать как в локальном (на одном компьютере), так и в сетевом (одноранговой или с выделенным сервером) режиме. При использовании сетевой версии достаточно важной является стоимость программы в пересчете на одно рабочее место, что позволяет определиться с необходимым числом приобретаемых лицензий.

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

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

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

И, конечно же, покупаемая программа должна удовлетворять самым общим требованиям — в части интерфейса пользователя, администрирования и безопасности, совместимости с другим ПО, справочной системы и документации.

Вот самые важные (с точки пользователя) требования для изучения, освоения и дальнейшего применения программы:

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

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

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

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

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

ВСТАВКА 1

Если Вы все-таки решили писать ПО, то…

  1. Помните о финансовых затратах. Если нет достаточных источников финансирования для ведения разработки ПО, то лучше ее не начинать. Нельзя начинать разработку без экономического обоснования всего объема предстоящих финансовых вложений. Средняя стоимость разработки «среднефункционального» ПО составляет не менее $150 000.
  2. Не вкладывайте большие деньги на начальных этапах проекта. Только после того как проект «пересечет экватор», ближе к тестированию и получению готового продукта, начинайте рассматривать проект с точки зрения его возможной законченности. Если выяснится, что проект нереализуем, то денежные потери будут незначительными.
  3. Не назначайте руководителем проекта программиста. Программист не может реализовать инженерную или предметную технологию, в которой не работал. Это будут лишь умозрительные построения на программистских знаниях, которых просто недостаточно для решения всей задачи.
  4. Руководителем проекта должен быть специалист с инженерным образованием и способный очень быстро вникнуть в проблемную область, или же умеющий создать методологию на основе консультаций со специалистами в предметной области.
  5. Не экономьте на людях. Если ради экономии вы не нанимаете специалистов для выполнения различных функциональных обязанностей, а пытаетесь взвалить все на одного человека, ждите отрицательного эффекта. Например, если вы хотите нагрузить тестера еще и обязанностями технического писателя (одна зарплата за две работы, вроде бы выгодно), то в случае если тестер уволится, «подвиснут» сразу два этапа проекта.
  6. Никогда не экономьте на руководителе проекта или заключайте с ним контракт. В противном случае при его увольнении очень велика вероятность потери инвестиций в проект.
  7. При реализации крупного проекта руководитель проекта обязан следить за построением работающей инженерной конструкции, а не за выполнением программного кода и реализаций алгоритмов на языке программирования.
  8. Разделите проект разработки на фазы со значимым конечным результатом, а каждую фазу — на промежуточные этапы, по результатам которых можно наблюдать прогресс в развитии проекта. Анализируйте тенденции и принимайте соответствующие меры.
  9. Помните о динамике программистского проекта, которую нужно стимулировать. В случае ее отсутствия проект можно закрывать.


ЧИТАЙТЕ ТАКЖЕ:
КНИГИ ПО ТЕМЕ:
Внедрение искусственного интеллекта в бизнес-практику. Преимущества и сложностиВнедрение искусственного интеллекта в бизнес-практику. Преимущества и сложности
Карьера менеджера IT-проекта. Как устроиться на работу в ведущую технологическую компаниюКарьера менеджера IT-проекта. Как устроиться на работу в ведущую технологическую компанию
Совместимость. Как контролировать искусственный интеллектСовместимость. Как контролировать искусственный интеллект

Отзывы

gk
Согласен на 100% с автором статьи. Каждая компания должна заниматься своим бизнесом. Одни пишут программные комплексы, другие их покупают и используют для ведения своего бизнеса. От таких схем выигрывают и первые и вторые.
ИТ отделы предприятий должны заниматься эксплуатацией задач а не программированием.
2004-07-14 13:21:56
Ответить

jossariann
Если бы не реклама собственного продукта в первых строчках статьи, было бы очень похоже на наброски для дипломной работы.
2004-07-18 21:14:45
Ответить

dr-Wicked
Плохо себе представляю это … в качестве подсистемы планирования-менеджмента ресурсов. А человеко-часы и на калькуляторе бабка-пенсионерка посчитают (думаю и на счётах). При цене бабки $50 в месяц (всё равно ничего делать ненадо, работа надомная) и $10 за калькулятор она эффективно заменит компьютер стоимостью $1000 и сроком службы 2 года. Дополнительный штат на сопровождение внедрение не потребуется.
2004-07-29 14:51:10
Ответить

Вадим, lettervadik@list.ru
>Но пока на предприятии >разработают свою программу, >разработчики тиражируемого >решения устранят эти недостатки.

Но что же делать, если недостатки обнаружены только для этого предприятия?

>Постановка задачи у компании->разработчика по определению будет >лучше, так как, кроме владения >предметной областью, есть и >понимание программистских >аспектов.

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

>Но, может быть, проще поменять >технологию, чем самим начинать >разработку.

Однако что значит поменять технологию? Конечно, стандартизация технологий позволила бы существенно повысить качество информатизации, но реально ли это сделать сейчас? Для средних и тем более крупных предприятий ответом, скорее всего, будет "нет" ввиду высокой сложности этого процесса. Да и нужно учесть высокую вероятность того, что при принятии единого стандарта для некоторых предприятий потребуется значительная модификация технологий а для других - меньшая. А кому захочется перестраивать свою работу в то время как конкурент может "не отвлекаться" Как писал Оруэлл (правда, совсем по другому поводу): "допустить это как перспективу вовсе не то же самое, что думать, будто ... такое возникнет со дня на день"
2004-09-07 09:46:39
Ответить

Boris, boris@pekao.com.ua
Не понравился тон статьи.Черно-белое мышление и менторский тон. Почему автор считает, что специалисты-"профессионалы" знают предметную область лучше, чем те, кто в ней работает - "любителей"? Догадываюсь, какой смысл вкладывает автор в слово "любители", но светлее на душе не становится. Видал я шедевры некоторых "профи". Для их сопровожденияя порой требуется еще больший профессионализм. Я тот самый "самописец", "сидящий в банке". Занимаюсь "любительским" программированием около 15 лет. Со многим, о чем пишет автор согласен, но и о "профессионалах" наслышен. Когда-то я благоговел перед продуктом одной ОЧЕНЬ известной фирмы-разработчика банковского ПО, зная о нем только из самохвалебных релизов пока мой товарищ, мнению которого я доверяю, не стал работать на нем и не поделился со мной некоторыми ужасами.
Давайте будем объективными.
Спасибо за назидание (вставка 1).
2004-09-30 17:09:37
Ответить

Владимир Самойленко, vlad@dpg.com.ua
И согласен и не согласен с автором одновременно.
согласен
1. Для многих свой программер действительно альтернатива, только люди не учитывают фактора того, что они будут делать когда программер все сделает, когда он уйдет в отпуск, уволится ввиду повышеной загрузки.
2. Многие клиенты не могут четко сформулировать задачу на ПО, а тем более управлять проектом по его созданию.

не согласен
1. Коробочное ПО не факт "удобства и профессионализма разработчиков". Могу привести массу примеров кривости рук и непродуманности взаимодействия с другим софтом. Лично я сторонник "самописного ПО".
2. Заказчик априори ставится как любитель, по сравнении с которым разработчик пуп земли. Это же отностися и к персоналу клиента.
3. "Тиражируемая система не требует доработки со стороны разработчика, и пользователь должен принимать ее как есть" - такой подход оправдан для Микрософт, при использовании идеологии избыточной функциональности. ПО для автоматизации учета подганяется под каждого клиента ИНДИВИДУАЛЬНО. Нет фирм с одинаковыми бизнес процессами. Процессы подобны в целом.
2005-05-26 01:20:10
Ответить

nyncuk, nyncuk@gmail.com
Откройте для себя мир мир софта под GPL. Никаких ушедших в отпуск программистов, никаких привязок на всю жизнь к одной и той же фирме-ведору. Единственный минус - требует в штате IT по крайней мере одного человека с IQ по крайней мере не отрицательного. Ну и умения разобраться в чужом коде - кстати, редкость. Если у Вас есть такой сотрудник, берегите его. Удачи, только не надо изобретать велосипед снова.
2007-05-02 01:27:22
Ответить




МЕТОДОЛОГИЯ: Стратегия, Маркетинг, Изменения, Финансы, Персонал, Качество, ИТ
АКТУАЛЬНО: Новости, События, Тренды, Инсайты, Интервью, Бизнес-обучение, Рецензии, Консалтинг
СЕРВИСЫ: Бизнес-книги, Работа, Форумы, Глоссарий, Цитаты, Рейтинги, Статьи партнеров
ПРОЕКТЫ: Блог, Видео, Визия, Визионеры, Бизнес-проза, Бизнес-юмор

Страница Management.com.ua в Facebook    Менеджмент.Книги: телеграм-канал для управленцев    Management Digest в LinkedIn    Отслеживать нас в Twitter    Подписаться на RSS    Почтовая рассылка


Copyright © 2001-2023, Management.com.ua

Менеджмент.Книги

телеграм-канал Менеджмент.Книги Менеджмент.Книги — новинки, книжные обзоры, авторские тезисы и ценные мысли из бизнес-книг. Подписывайтесь на телеграм-канал @books_management



Спасибо, я уже подписан(-а)