IT для бизнеса: как заказчику не стать рабом компьютерного приложения?

При разборе материала не учтена главная проблемная сторона использования и внедрения программного обеспечения в деятельность компании. И в особенности, в России. А именно, - что любая компания нуждается только в той части бизнес-элементов программного приложения, с которой напрямую связана обслуживаемая ей деятельность. Остальные бизнес-элементы действительно остаются невостребованными за ненадобностью, однако компания вынуждена всё равно платить за них, т.к. единый пакет под индивидуальные потребности компании никто переделывать не будет. В России доходит до того, что компании используют предлагаемые им стандартизированные бизнес-пакеты всего на 10-12%.

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

Именно поэтому разработчики всеми правдами и неправдами стремились и будут стремиться ''впихивать'' в в п/о как можно больше всего, - нужного и ненужного, - главное, чтобы было более развито, чем у конкурентов, заправшивая с клиентов по полной стоимости разработки за весь создаваемый таким образом программный пакет. Без учета индивидуальных особенностей каждой организации (или групп организаций), ее потребностей и компетентности персонала, переваливая всю ''вину'' на нее, - дескать, ''у нас-то всё хорошо, это у вас никто работать не умеет и не оценивает всей глубины того, что мы для вас сделали !''.

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

Романов Николай пишет: При разборе материала не учтена главная проблемная сторона использования и внедрения программного обеспечения в деятельность компании. И в особенности, в России. А именно, - что любая компания нуждается только в той части бизнес-элементов программного приложения, с которой напрямую связана обслуживаемая ей деятельность(1). Остальные бизнес-элементы действительно остаются невостребованными за ненадобностью, однако компания вынуждена всё равно платить за них, т.к. единый пакет под индивидуальные потребности компании никто переделывать не будет(2). В России доходит до того, что компании используют предлагаемые им стандартизированные бизнес-пакеты всего на 10-12%(3).

Николай, не чувствуете некоторого противоречия между выделенными фрагментами (1) и (2)? В первом выделенном фрагменте вроде бы нужно ''вынуть'' несколько элементов программного обеспечения. Создается иллюзия, что это можно сделать нажатием нескольких кнопок. Во втором случае появляется ключевое слово ''переделать''. Оно предполагает наличие процесса определенной продолжительности, который требует ресурсов. А за рамками осталось сопровождение каждого из ''переделанных'' программных приложений. Представьте себе, для этого нужен штат, умноженный на N, где N = количество ''переделанных'' клонов. Есть вопрос по высказыванию (3). Какие именно ''стандартизированные бизнес-пакеты'' используются на 10-12%? И чем это обусловлено? Мне известны компании, которые используют проибретенные бизнес-пакеты на 0%... но не потому, что они им не подходят :)

Прежде всего - спасибо e-xe, за материал. К сожалению, не имел ранее возможности услышать (или прочитать) мнение специалиста, настолько хорошо представляющего себе (сподобившего приоткрыть завесу) проблемы взаимоотношений Разработчика и Заказчика управленческого ПО.
Не вполне согласен со стартовой посылкой ''... нужна ли компании система автоматизированного управления предприятием...''. Нет компаний, которыми управляют автоматизированные системы. Компаниями управляют люди. Именно люди, управляющие компаниями несут всю полноту ответственности за результаты деятельности. Такое уточнение, думается, более точно отразит роль и место автоматизированной системы в управлении предприятием. Неспроста, очевидно, достаточно востребованы программные компоненты, автоматизирующие ввод информации в систему и формирование документов первичного учета. Т.е. той части программного комплекса, который осуществляет наполнение информацией и вывод стандартизированных выходных форм.
Сыр-бор, как правило, случается при формировании алгоритмов обработки накопленной информации и в еще большей степени - при интерпретации результатов такой обработки. Именно в этих аспектах и проявляется ''человечность'' системы. Именно в решении этих задач, западные системы проигрывают нашей нелюбимой 1С. Почему? Потому, что лукавят. Потому, что прячут алгоритмы обработки и интерпретации в закрытые модули. Развитие бизнеса характеризуется увеличением оборотов, т.е. увеличением как количества, так и качества (весомости) обрабатываемой информации. Можно привести, в качестве аналогии, процесс прохождения трассы в Формуле-1. Трасса исследована, болид можно настроить идеально под совокупность поворотов и прямых участков каждой конкретной трассы. И результат расчетов заложить в качестве управляющей программы. И вот, представьте себе, в повороте, для которого запрограммирован угол поворота 30 градусов при скорости 80 км/час, Шумахер хочет пройти с более ранним вхождением в поворот (угол 28 градусов) на скорости 85 км/час. По аналогии с предлагаемыми программными пакетами и методикой их поддержки, он (Шумахер) должен в письменном виде изложить свои предложения (с подписью), которые будут рассмотрены коллективом специалистов (на следующей неделе, т.к. рабочее время всех специалистов распланировано) и, по результатам рассмотрения будет принято решение о методике корректировки программы. Бред? Несомненно. А предлагать такую методику для бизнеса? ...
Аргумент применения западных программных пакетов для ''увеличения прозрачности'' тоже притянут за уши. Если они согласны доработать методику под мои требования (и за мои деньги), то о прозрачности можно забыть, если я квалифицировано изложу свои требования.
Таким образом владелец бизнеса оказывается перед альтернативой. Приобрести (и эксплуатировать) добротно (возможно) сделанный и обеспеченный поддержкой (постоянно запаздывающей и недешевой) западный программный пакет или воспользоваться 1С с привлечением местного умельца, коих уже довольно много и их разработки и уровень сопровождения далеко не ''на коленке''.
Аргументация необходимости содержать большой штат ''доработчиков'', на мой взгляд имеет право на существование. Но. В
промышленности (мировой) давно сложились понятия взаимозаменяемости и существуют комплексы стандартов, позволяющие эту взаимозаменяемость обеспечить. И что же мы видим? Даже там производители стараются эту взаимозаменяемость усложнить и заставить покупателя приобретать полностью новое изделие. В области разработки ПО ситуация еще комфортнее для Разработчиков. Экономя на методической постановке они отдают логику работы программы на откуп кодеров. Попробуйте воспользоваться поддержкой Разработчика в ситуации, когда конкретный специалист, отвечавший за доработку, отсутствует. От того, кто будет заниматься этим вместо него, вы услышите такую красочную характеристику образовательного уровня предшественника, что задумаетесь, не дешевле ли содержать своего постановщика.

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

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

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

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

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

Согласен. Не буду повторяться, дам ссылку в подтверждение

>В первом выделенном фрагменте вроде бы нужно ''вынуть'' несколько элементов программного обеспечения. Создается иллюзия, что это можно сделать нажатием нескольких кнопок. Здесь нет никакого противоречия и не нужно его искать. Я написал только то, что написал. Без всяких ''вроде бы'' и прочих ''может быть''. Кто, как и что понял, - это вопрос индивидуальный. Тем более, что вопрос и его содержание были не в этом. Но в любом случае, - извольте. Применительно к п/о, - в принципе, не играет существенной роли, как вы достигнете поставленной цели, - путем ''вынимания'', т.е. программного отключения или удаления некоторых модулей с сопутствующей блокировкой связанных с ними функций, что обойдётся вам и проще и дешевле, или путем упомянутого ''переделывания'' прикладного программного массива, когда подобная схема отключения платных модулей не предусмотрена и в каждом индивидуальном случае потребуется серьёзное внесение изменений в тело программ. Но вот с точки зрения оперативности работы, цены и трудозатрат, - разница будет существенной. Поскольку во втором случае процесс будет однозначно затратнее, т.к. не предполагает подобной модульной удешевленной схемы работы и отключения ненужных модулей. По аналогии с тем, как в первом случае дело ограничилось бы отключением неких разъемов и удалением неких рабочих блоков или плат (или с сохранением их на месте, без удаления, но с временным отключением шлеек), а во втором, - по сути, осуществлялось бы то же самое действие, - с тем же удалением ''железа'', - но путем сложной пайки, перепайки контактов, как в советском электронном оборудовании. Применительно к России, - применяемое сегодня офисное специализированное п/о относится по большей части именно к указанной выше советской аналогии. И то - в лучшем случае. Т.е. что-то в нем отключить программно или аппаратно, не затронув всю программу в целом, невозможно. К тому же, если разработчик не получает ''сырой'' материал с Запада и не адаптирует полузнакомую программу под российские нужды. А если получает, то он в принципе изменить что-либо серьёзно в ней не может и запускает в продажу в доадаптированном виде. И ничего менять по существу не будет. За рубежом иначе. Т.е., например, можно заказать стандартный или даже расширенный ''SAS''-пакет, в котором присутствует всё, что было туда ''по умолчанию'' заложено компанией-разработчиком, заплатив за это очень большие деньги, а можно выбрать из предложенного функционального списка только то, что потреубется для работы, выбросив всё ненужное. Как результат, - пакет приходит именно в таком ''кастомизированном'' виде, а цена на него снижается более чем ощутимо. Естественно, отключенные функции в нем присутствуют в виде ''покрывшихся пылью'', т.е. заблокированных. Т.е. всегда можно увидеть, что в принципе входит в этот ''SAS''-пакет в стандартной или расширенной комплектации и всегда дозаказать за определенную плату некий странный номерной патч, который активирует работу именно тех или иных до того отключенных функций, которые вдруг понадобились клиенту. Т.е. человек пользуется только тем, что ему реально нужно и платит только за это, а не за всё, что есть в принципе. Тем более, что при желании и владении навыками работы в области программирования, клиент и сам может индивидуальным образом написать для SAS некую программу, - дублирующую оригинально заложенную в пакет, но заблокированную функцию. SAS был приведен в качестве примера. Но подобных вещей в п/о здесь встречается очень много. Пожелания клиента уважаются и его не заставляют платить за ненужный балласт или его поддержку. >Какие именно ''стандартизированные бизнес-пакеты'' используются на 10-12%? ''Бисквит'', ''Инверсия'', ''Новая Афина'', ''RS-BANK'', ''ЦФТ-Банк'', ''Diasoft'', ''OpenWay'', ''Unisab''. Достаточно будет ? >И чем это обусловлено? Я уже ответил на этот вопрос. Люди вынуждены пользоваться тем, что им предлагают, - тем, что есть на рынке. Платя лишние деньги за невостребованные и ненужные им функции, которые вложены в предлагаемый программный пакет. Не имея возможности отказаться от них, следствием чего стало бы удешевление приобретения такого пакета для клиента, но создало бы трудности для разработчика. Становясь тем самым в зависимость от гениальных идей разработчиков, искусственно за счёт своих разработок упрощающих бизнес-процесс и доводящих его до уровня некоторой клишированной схемы. Или клиенты вынуждены писать нужные им программы сами, ''на коленке'', как было в начале 90-х, что сегодня становится всё более сложным делом.

Романов Николай пишет: При разборе материала не учтена главная проблемная сторона использования и внедрения программного обеспечения в деятельность компании. [...] Любая компания нуждается только в той части бизнес-элементов программного приложения, с которой напрямую связана обслуживаемая ей деятельность.

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

Валерий Корчевский пишет: Не вполне согласен со стартовой посылкой ''... нужна ли компании система автоматизированного управления предприятием...''. Нет компаний, которыми управляют автоматизированные системы.

Валерий, вы правы. Спасибо, что обратили внимание. Исправил.

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

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

>Отсюда - обвинения в адрес подрядчиков по поводу искусственного завышения цены проекта за счет ненужных опций/модулей в ПО. :) Раз есть эти самые ненужные модули, то всё-таки не учтена. Интересно другое, - когда я покупаю п/о в США или здесь, в Европе, дизайн которого выполняется под мой индивидуальный пользовательский заказ, - я выбираю абсолютно всё, что считаю нужным, как и выбрасываю из ''флакона'' всё лишнее. Если не дай бог что-то из указанного мной в формуляре к удалению будет оставлено, - суд снимет с продавцов ''стружку'' по полной программе. Т.к. клиент платит только за то, что заказал на основани иусловий договора на п/о. А всё остальное, - если компания по какой-то инициативе оставляет это во ''флаконе'', - считается предоставленным ей клиенту бесплатным образом без какого-либо права требовать за это оплату или плату за сервис, обслуживание, поддержку и т.д. В России этого нет и не предвидится. Отсюда и проблемы. Впрочем, компании на Западе всё равно находят способ выхода из сложившейся ситуации, проводя крайне узкий селективный маркетинг внутри собственной товарной группы и незначительно повышая цены на наиболее популярные рабочие модули, компенсируя тем самым в той или иной части потери от неиспользованных или не установленных программ. Или же снижая цены на такие, не пользующиеся популярностью модули. Формируя своеобразный внутренний рынок внутри одного предоставляемого ими продукта. Но обычно они не сильно этим увлекаются, чтобы не проиграть конкурентам в соотношении цена/сервис на общем уровне. Есть, кстати, еще одна ''хитрость'', заключающаяся в том, что разработчики набивают свой ''софт'' откровенным балластом, основная цель которого - максимально большая загрузка машинных ресурсов самым непроизводительным образом. Но это обычно проявляется в том случае, если разработчики п/о в той или иной степени связаны с изготовителями ''железа'' или выступают вместе с ними совместно против неких конкурентов, действующих на определённом рынке.

Евгений Купраш пишет: Если я правильно понял, вы говорите о ''коробочных решениях'', которые не потребуют тонкой настройки силами программистов. И даже могу себе представить сегментацию таких продуктов по направлениям: CRM для интернет-магазина, для химчистки, для автосервиса и т.д. Но пойдет ли сегментация дальше или останется на этом же уровне?

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

Глупо винить заказчика в неумении объяснять или пользоваться на 100% какими-то программами.
Если разобраться, бизнес был создан НЕ ДЛЯ дискуссий с разработчиками программного обеспечения. И персонал компании НЕ ОБЯЗАН мыслить и говорить алгоритмами и тем более знать основы программирования - персонал обязан выполнять те обязанности, за которые ему платит руководство компании.
И противостояние существует только в одном месте - в головах разработчиков ПО. По-моему, они слабо понимают, что программа существует для обеспечения потребностей конкретного специалиста. А специалисты бывают не только в области программирования, но и в области продаж (да, не удивляйтесь, господа разработчики!), в области финансов и в множестве других областей. И раз они работают в этих областях(и способны заплатить за услуги по установке программного обеспечения), то вероятно, они на самом деле профессионалы.
Но, когда какой-то умник написал программный код и не умеет сделать его человекопонятным (интерфейс сделать) - тут много вопросов к его профессионализму.........
Ну и еще немного мыслей: если никак не получается наладить диалог с представителями ''клана непрограммистов'', если это вызывает раздражение и плохое настроение, то пора задуматься о смене профессии. Потому что на негативе хорошего бизнеса не сделать :D