Pull to refresh

Comments 22

Да, по статье в вики выглядит прямо очень похоже на решение описанной проблемы, спасибо! Сами мы с ним не сталкивались, какие у вас впечатления от него, насколько сложно начать работать?
Мы его используем как средство совместной работы, и как корпоративный портал. Могу сказать из опыта, что сам по себе Sharepoint ничего не решает. Это, грубо говоря, просто платформа для разработки и плюс хранилище файлов с версионностью. Ключ к решению указанной проблемы лежит в области организации бизнес-процессов. Без переделки этих самых процессов, а самое главное — без переделки привычек пользователей, Sharepoint вам просто даст еще один способ обмена Excel-файлами, и только. В нем также будет бардак.
В практике очень часто SharePoint используется для хранения актуальных версий DOC, PPT и XLS файлов. Несмотря на возможность делать более умные вещи. Часто процесс строится по принципу: «так, давай-ка я скачаю свежую версию формата отчета и сделаю отчет за этот месяц» — «подожди, не скачивай, я еще не залил новую» — «надо будет попросить все же программистов написать нам эту бизнес-аналитику» — «лень писать техническое задание».
Но ведь офисные файлы, начиная с 2007, вроде, версии поддерживают совместное редактирование, я даже им пользовался и оно даже работает
Расскажите об этом тем людям, которые пользуются этими инструментами. Плюс: у конечного пользователя всегда есть соблазн «если я не буду использовать этих продвинутых функций — то точно ничего не слетит. Вот я как-то нажал эту кнопку и все зависло\сломалось\неправильно считается». Особенно проблемно, когда этим конечным пользователем является более или менее начальствующий человек (нач. отдела из 5 человек, например).
Да, про это немного есть в статье (имею ввиду Google Spreadsheets) — они решают проблем пересылки файлов по почте, но при этом не решают многих других проблем: если данные становятся сложнее чем одна таблица или список, например когда про одни и те же объекты разные люди вводят разную информацию, может получится дублирование или необходимость повторного ввода по сути одних данных. Самый простой пример — в одном месте мы ведем справочник объектов (клиенты/пользователи и т.п.), в другом про них что-то вводим (цены/звонки/продажи), и тут перевводить данные про исходный не хочется, но хочется видеть про него разную информацию. А в третьем месте хотим видеть отчет по числу звонков или суммарным продажам. Плюс то что написано выше про объем данных и интеграцию.

Но для каких-то случаев гугл-доки вполне нормальное решение, сами их используем активно.
Самый простой пример — в одном месте мы ведем справочник объектов (клиенты/пользователи и т.п.), в другом про них что-то вводим (цены/звонки/продажи),
Погодите.
Мы говорим про сводную информацию, или детальную?
Для клиентов/пользователей/звонков/продаж используют CRM.
В excel только выгрузка сводной информации.
Для клиентов/пользователей/звонков/продаж используют CRM.
В excel только выгрузка сводной информации.


Да, если можно все вводить в CRM, это уже хорошо, сильно упорядочивает процесс. Пример был про то, почему google docs не решают всю проблему, возможно не совсем в тему.

Для построения отчетов часто нужна детальная информация (или выгрузки в разных разрезах), но в целом со схемой когда данные вводятся в CRM, дальше автоматом через API перегружаются в гугл-доки и в них всегда актуальные отчеты, наверное тоже можно жить, пока хватает возможностей гугл-докс для анализа и не появляется других источников информации.
x_x

$ x_x dead_guys.xlsx
+---------------+--------------+
| A             | B            |
+---------------+--------------+
| Person        | Age at Death |
| Harrold Holt  | 59.0         |
| Harry Houdini | 52.0         |
| Howard Hughes | 70.0         |
На самом деле задача про Машу и Петю правильно решается только использованием программного обеспечением Point of Sale, коих есть великое множество. Например Retail Pro и Cegid. Ведь далеко не обязательно PoS используется только там, где есть кассовые терминалы. На самом деле работа с терминалом — это лишь часть функционала PoS системы.
Вы предлагаете решение «чуть лучше Excel», что в принципе не решает задачу.
Задачу автоматизации бизнес-процессов можно решить только комплексными ERP-решениями, которые дороги, мучительны в интеграции, но в конце концов работают.
Результат внедрения таких решений очень болезненный для распиздяев менеджеров низшего и среднего звена, но при должном усердии команды внедрения и правильной политике руководства крайне положительно сказывается в долгосрочной перспективе на всём бизнесе.
На эту тему сломано уже немало копей, но «серебрянной пули» до сих пор нет. Да, наверное, и не может быть в принципе. Бизнесы разные, люди разные, обстоятельства разные. Невозможно в этих процессах формализовать вообще всё, и уж тем более предложить решение «на все случаи жизни».
Да, на «серебряную пулю» мы и не претендуем. Сейчас мы проверяем гипотезу, что
1) есть небольшие компании или отделы, работа которых сейчас строится прежде всего через Excel
2) они недовольны этой ситуацией по описанным в статье причинам
3) стандартные ERP (или более специализированные) решения или слишком сложны/дороги во внедрении, или требуют слишком существенных доработок

Если задача прежде всего в формализации/автоматизации бизнес-процессов (упор на слово процессы), то это уже 100% задача ERP, согласен. Нам интересны ситуации когда сам процесс не сложный или не формализованный, а упор больше на порядок в данных и на анализ.
Искать по ключевому слову PowerPivot. Часть проблем описываемых вами решается им через линк к бд, а вот кто эту бд редактировать будет другой вопрос, можно тем sharepoint'ом, но если будет шарик то зачем вам такой excel непонятно.

P.S. Я полистал ваш сайт, и откровенно не понимаю чем продукт отличается от SQL Server с настроенными через импорт файлов +powerpivot??
Да, про PowerPivot в этом контексте мы не думали, спасибо за наводку!
SQL Server + импорт файлов + PowerPivot означает, что пользователи вводят данные в excel, дальше они автоматом попадают в SQL Server, и по ним можно строить отчеты при помощи PowerPivot, правильно? Если так, то основное отличие у нас в том, что это один продукт, который проще настраивать/менять модель данных, плюс всякие менее существенные тут отличия вроде наличия истории изменений.
В целом эта связка (sqlserver + excel + powerpivot) выглядит интересно, если позволяет прямо из Excel в базу писать данные.
Не совсем так как вы говорите, но на предыдущей работе наш dba делал такое, только через макросы и кнопочку «сохранить».
Есть ещё немаловажный момент — Excel очень распространен в корпоративной среде за счёт вхождения в пакет MS Office. Зачастую, это единственный инструмент, который есть в распоряжении практически у всех. И вот начинается цирк с конями: кто-то за счет макросов и\или Access-а начинает превращать Excel в монстра, кто-то распарсивает огромные файлы опять же в Excel-формат и с ними уже работает и тд. Другими словами, Excel, при всех своих недостатках, часто единственное решение проблем.
Лично я вижу решение этих проблем бизнеса в своем маленьком отделе разработки, который взаимодействует напрямую с бизнесом и пилит их реализую бизнес-процесса. Почему этот вариант? Бизнес иногда настолько многогранен, что натягивать на ERP/СRM или еще какую систему выходит дороже и дольше, чем проще посчитать в экселях.
Да, это отличная штука, был у них на семинаре недавно, и сам потом поработал. У нас идея в том, что модуль анализа построен на том же принципе и позволяет быстро и удобно смотреть на данные под разными углами, но в отличие от QlikSense/QlikView есть возможность ввода и редактирования данных непосредственно в системе. Т.е. у нас in-memory вычисления на лету синхронизируются с базой, в которую через тот же интерфейс возможен ввод данных, а у QlikView write-back идет только в память — они специализируются на задаче анализа.
Мне казалось что термин «Excel Hell» описывает наличие русской и английской версии Excel-я в одной конторе.
Sign up to leave a comment.

Articles