serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Лучше меньше, но лучше - или всего помаленьку?
serge_gorshkov
Недавно участвовал в споре на тему о том, какие приложения для автоматизации бизнеса более актуальны (полезны, рыночно перспективны): решающие одну, частную задачу, но решающие ее максимально полным образом, или такие, которые стремятся удовлетворить все или большую часть потребностей предприятия. Примером первого типа приложений может быть "Мегаплан", или, скажем, "МойСклад". Примером второго типа - сложные конфигурации 1С, любые развитые CRM или ERP-системы. Как правило, в любой CRM есть планировщик, но он заведомо проиграет Мегаплану по красоте и удобству; с другой стороны, планировщик в отрыве от клиентов и контактов гораздо менее полезен.
Буду рад услышать ваше мнение: приобрели бы вы, как руководитель, такое бизнес-приложение, которое решит только одну локальную задачу, но решит ее хорошо?

Poll #1858399 Что полезнее - специализированные или универсальные бизнес-приложения?

Приобрели бы вы, как руководитель, такое бизнес-приложение, которое решит только одну локальную задачу, но решит ее хорошо?

Да, без сомнения!
2(15.4%)
Только если специализированное приложение очень понравится.
5(38.5%)
Вряд ли, только если не будет другого выхода.
3(23.1%)
Ни за что! Бизнес-приложения должны решать максимально широкий круг задач, или хотя бы интегрироваться друг с другом.
3(23.1%)

  • 1
Бизнес очень часто работает по принципу "Лучшее - враг хорошего"...

А где вариант опроса "да, если нормально сумеет интегрироваться?"
Например 1С, не знающая ни ИМАПа ни ССЛ это тоска в плане интеграции с почтой.

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

Если оно хорошо интегрируется с остальным у меня - да, конечно. Причем интеграция нужна из коробки.

Добавлю - я ещё и остальным с удовольствием продам :)

Добрый день, Сергей! Очень полезный пост. Не могли бы Вы сделать его, вместе с опросом, в сообщество Бизнес-дайджест http://business-digest.livejournal.com/

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

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

И тогда возникает выбор:
1. начать тратить ресурсы на его доработку и/или интеграцию с другими приложениями (если это возможно), или
2. заменить на другое, более функциональное приложение, или же
3. навсегда смириться с его несовершенством.

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

Мне только кажется, или напрашивается вывод, что лучше вообще не связываться с узкоспециализированными приложениями?

не знаю, не знаю

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

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

А мегаплан (он же у вас используется АФАИР) с на чем вы регламентированную бухгалтерию ведете нормально подружился, или контрагентов по два раза вводите?

мы его не дружили - в Мегаплане мы клиентский контур не используем. Используем только систему постановки задач, контроля трудозатрат, общие документы. CRM пока не пользуемся (может, когда-нибудь и придем к ней).


То есть и задачи без заказчика, и список работ за месяц по клиенту в один клик не соберешь.
Или вы все равно только проектами занимаетесь, и сколько на клиента времени потрачено для клиента не интересно, а вам для контроля себестоимости важен только баланс времени и денег по проекту ?

Edited at 2012-08-07 02:53 am (UTC)

так и не так :)

видели МП изнутри?
там есть проекты, есть задачи в проектах.

Проект верхнего уровня - заказчик.
Проект второго уровня - проекты данного заказчика.
Далее уже вложены непосредственно задачи.

Таким образом, посчитать объем трудозатрат по проекту, по клиенту, список работ и так далее - не проблема, мы это постоянно делаем.

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

Просто клиент в МП для нас не существует как совокупность реквизитов: ИНН, КПП, юрадреса, банковского счета и так далее. Счета мы в МП не выставляем, и оплаты не заводим.

Ясно. Кстати, насколько пользователи (клиенты) обучаемы метатрейду? более менее рядовых пользователей 1С можно пускать задачи-обращения рисовать, или только представителей с особыми полномочиями со стороны клиентов пускаете?
(стоит у меня задача как-то отображать статус заявок пользователей самим пользователям, думаю что за инструмент лучше использовать.)

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

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

Нет и не будет однозначного ответа для сложных систем. Всегда придется просчитывать конкретный случай. Учитывать различные финансовые, временные требования к системе и возможности Заказчика. Пример: "1C Бухгалтерия" и "1С Управление торговлей". Обмен "из коробки" как бы есть, но в силу разного, в том числе, постоянного апгрейда программ, он нуждается в периодической поддержке и перенастройке. Выход- объединенная комплексная программа. Но, не всем она нужна. Для кого-то обмен данными необходим раз в пол-года. А там, где средств интеграции изначально нет, следует их написать и протестировать. Разработка может вылиться дороже, чем достаточно навороченное опять же комплексное тиражное решение. С точки зрения проектировщика баз данных, не следует множить сущности (хранить 1 и то же в разных программах и синхронизировать), ибо обязательно через некоторое время это "одно и то же" будет уже разным. Это критично, когда предполагается, что данные все-таки перетекают между системами с определенной периодичностью, но вот в том случае, о котором упомянули выше синхронизация базы данных клиентов программы "Тимвьювер" и по сути таких же контрагентов в 1С, скорее, и не нужна.

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

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

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

  • 1
?

Log in

No account? Create an account