Михаил Елашкин - SAP Business One. Строим эффективный бизнес

• Название: SAP Business One. Строим эффективный бизнес
• Автор: Михаил Елашкин
• Издательство: КУДИЦ-ПРЕСС
• Жанр: Прочая околокомпьтерная литература
• Год: 2007
• ISBN: 978-5-91136-041-2

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

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

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

---

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

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

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

7. Стоимость владения всегда выше цены покупки.

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

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

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

Для оценки экономического эффекта используются стандартные экономические критерии.

• ТСО — Total Cost of Ownership, или Общая Стоимость Владения, рассчитывается исходя из всех затрат на технологию, включая неявные затраты.

• ROI — Return of Investment — Возврат Инвестиций.

• VCO — Visible Cost of Ownership — Видимая Стоимость Владения, отличающаяся от ТСО тем что в нее входят только прямые затраты, видимые бухгалтерией.

• Время возврата инвестиций — время, за которое прибыль сравняется с начальной стоимостью проекта. Этот параметр — ключевой для оценки рисков и не зависит от размера инвестиций. Чем быстрее возвращаются вложенные деньги, тем выгоднее проект.

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

[ Мао Цзе-Дун, «Заботиться о жизни масс, уделять внимание методам работы» Избранные произведения, т. I ]

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

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

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

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

• Масштабируемость

• Надежность

• Управляемость

• Опора на стандарты

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

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