Тема: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Автор: Автор: Шатунов Виталий Иванович <shatunovv@incom-auto.ru>  

Дата: 26.10.2005 13:17

Из ответа сотруднику, который отослал меня на эту статью.
Внимательно почитал «почиталку»...
Я бы согласился с автором (впрочем во многом согласен и более того считаю, что основные программные продукты – финансового и складского учета должны быть именно «фирменными» [здесь и поддержка изменений в законодательстве и отчетности и важные прочие мелочи], однако когда необходимо быстро и оперативно решить какие-то локальные задачи (или задачи не требующие строгой финансовой отчетности), то думаю нужно использовать свои умственные резервы.
Например:
Программа складского учета «Фолио» (все что напишу далее все правда – свидетель Славин)
Установлена в тех/центрах Инкома с 2002 года. Впервые вплотную с ней столкнулся в августе 2002 года.
Программа интересная, но масса недоработок, недоделок и неувязок. При этом сталкиваться приходится с таким безобразием в процессе работы (все это влияет на производительность, истинность отчетных и вычисляемых данных). Причем некоторые подводные камни вылезают, когда поезд ушел.
Например пришлось очень длительное время (с конца 2002 года до мая 2004) с ними бодаться, в том, что у них неправильно рассчитывается учетная цена товара, а они доказывали, что правильно (при этом пришлось самому перелопатить гору материалов по законодательству, бухгалтерии, консультироваться у специалистов по фин.учету). В конце концов выяснилось, что действительно расчет учетной цены, предусмотренный законодательством (по средней, скользящий метод оценки) у них не прописан и только тогда они в срочном порядке доработали программу. Не говорю уже и о других просто откровенных ляпах.
При чем интересен факт – наши замечания к программе и предложения как решить проблемы и доработать программу ими принимались, программа дорабатывалась, но в большинстве не бесплатно!
При этом, в большинстве случаев, доработки приходилось испытывать на живом организме фирмы.
В одной из последних служебных записок по ошибкам и недоработкам программы насчитывалось порядка 28-30 пунктов.
Переход же на другую программу тоже связан с рисками попасть в такую же ситуацию. Incadea лишнее тому подтверждение.
Впрочем, как я уже сказал, я за фирменное ПО основных программ.
Надо понимать, что сложные по связям системы неповоротливы и не могут решить всех задач стоящих перед организацией (Это, что же будет за программа, которую доработают под фирму (а может просто под руководителя) так, что потом и концов не найдешь!). Согласись – сложные, разветвленные системы сложнее дорабатывать, изменять и настраивать.
Но не большие, оперативные и локальные задачи, как мне представляется, которые не могут быть решены в рамках «фирменной» программы или их решение в рамках «фирменной» программы по экономическим соображениям не целесообразно надо решать исходя из собственных ресурсов фирмы.
Так мне ка-а-атца (как выразился бы Райкин) J

26.10.2005 14:38 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Абсолютно согласен - всякую "малую механизацию" c помощью Accessa, Excel-a и какой-то матери можно и нужно делать внутри.

Но когда речь идет именно о более или менее амбициозной РАЗРАБОТКЕ, полностью занимающей ресурсы одного или нескольких программистов на срок неделя и более, и ставящей задачу не "затыкания дыр", а выдачи на гора какой-то СИСТЕМЫ, тут все мои аргументы вступают в силу.

А проблем взаимодействия с поставщиками - как правило, всегда выше крыши, и ничего нового тут нет. Но поверьте, если бы вы писали эту программу самостоятельно, проблем для фирмы было бы гораздо больше :)

>> >>