И не говорите со мной так, будто я написал одно из описанных выше решений и перед вами его защищаю, я к их разработке вообще никакого отношения не имею если что))
Руководитель подразделения крупного регионального банка.
Затем, чтобы не путаться в своих многочисленных поручениях и действительно контролировать, а не искать изменения\удаления в списках. Нигде не видел, изначально хотел чтобы подобное допилили на Exchange.
Я не продавец, но утверждаю что лично и не раз слышал о таких потребностях у не-госов.
Давайте спорить не будем — видимо вы встречаете одних заказчиков, а я других.
Я не ухожу от темы. Вы говорите про СЭД в целом, и я про СЭД в целом.
Про поле не совсем так, не упрощайте, и обратите пожалуйста внимание на строку «в самом простом случае».
Ок, мы выяснили, что какое-то решение на Sharepoint Server может оказаться дешевле чем тяжелая кастомизация на Foundation, при наличии нормальных спецов и четком понимании, что нужно сделать (не применительно к статье). Если выгоду измерять деньгах — без вопросов, такое возможно.
Другой вопрос, насколько это решение будет соответствовать функциональным потребностям и насколько им можно будет пользоваться (выгода от практического применения).
Как я понял, о чем разговор сейчас:
Вы говорите «сделать самим дешевле, продавцы СЭД на Sharepoint вас, как правило, накалывают», я говорю «нет, не накалывают».
Чтобы не быть голословнымм, приведу несколько (далеко не все) востребованных функций СЭД, которые сложно реализовать в шарике из коробки, и для которых в коробочных СЭД есть кастомизации:
1. Поля типа «расширенный лукап». Не стандартный лукап sharepoint (который не слишком удобен), а нормальный такой контрол, позволяющий искать подходящие организации (например) по инн, e-mail и на лету добавлять новые. Полезно при регистрации входящих писем.
2. Разграничение прав по полям. Особые права, например, требуются для поля «рег. номер».
3. Сложное (и быстро работающее, без потолка в 50 000) разграничение прав доступа. Не просто с наследованием от родительского элемента, а с многими хитрыми дополнениями.
4. Легко настраиваемые РП согласования, с возможностью запуска доп. согласований, условий, циклов, настройки прав на каждом этапе. Без Sharepoint Designer, в котором, даже для создания простого РП потребуется понимание того, что же внутри системы происходит.
5. Контроль и иерархия поручений.
6. Единое и настраиваемое рабочее пространство с задачами из разных разделов и удобным исполнением, с предпросмотром документа из окна исполнения задачи. Интуитивно понятный интерфейс риббона и других окон. Что, кстати, особенно важно для заказчика.
Влегкую заточенный под СЭД Sharepoint Server продать ему вполне можно, вот только он быстро взвоет от того, что какие-то простые вещи ему приходится делать через одно место, а для доработки звать дорогого специалиста. А звать придется точно, потому что ни один заказчик не знает в точности, что ему нужно. Вообще думаю, вы согласитесь с очевидной вещью:
«Продуманный аналитиками, протестированный множеством пользователей функционал и интерфейс пользователя сложной информационной системы, в среднем, намного лучше чем качественная одиночная кастомизация продукта, изначально под предметную область слабо приспособленного»
И весь вопрос сейчас в том, что вы считаете, что шарик для СЭД норм, а я считаю, что шарик для СЭД нужно серьезно доделывать. Если согласны, давайте говорить по существу этого вопроса, не отвлекаясь.
Согласен, с интеграцией получится тяжко. Но тут ресиверы будут меньшим из сложностей, кастомное решение в Sharepoint все равно придется синхронизировать кастомно.
По поводу сценария — попробуйте обновить решение на существующее семейство сайтов (накатив новый WSP с новыми ресиверами). У меня после такого приходилось проделывать танцы с Sharepoint Manager.
Про российский документооборот — любое крупное предприятие, подчиняющееся нормативному законодательству. Не было проблем у вас — не значит что их не было ни у кого.
Знаю как минимум 2 примера того, как в крупном предприятии устали от задач в Exchange (нет контроля, слишком много свободы у исполнителя и т.д.). Это про коммерцию. Про госструктуры — бумаги много, но это вершина айсберга. Руководитель с айпадом и ЭЦП вместо бумажек, контроль, сложный поиск документов, номенклатуры дел. межведомственный документооборот вы как будто не учитываете.
Покупают не только потому, что продажник ушлый(хотя и это бывает), а потому что во всем этом есть потребность.
Ваш пост говорит о том, что вы немного не разобрались в вопросе. И вот почему:
1. Да, Sharepoint Server классный, да там можно чудеса делать, но, повторю, настоящий российский документооборот с нормальным юзабилити и необходимым набором функций написать на нем стоит очень и очень дорого. Любому, кто представляет себе, что такое современная российская СЭД, ясно, что 16 часов — это фантастика. Даже для специалиста такого уровня как вы. Если нужно, могу аргументировать подробнее (о том, для чего все же приходится писать кастомизации).
2. Неясно, откуда вы взяли скидку в 90% для гос. ВУЗов.
3. Вы почему-то считаете стоимость времени разработчиков, хотя из статьи ясно, что речь идет о тиражируемом решении. Его установка, как правило, даже практически не требует усилий разработчиков и специалистов по Sharepoint.
4. Вы делаете акцент на доработках вроде создания приложения-службы и собственной БД как поводе для покупки. В XXX for Sharepoint это скорее приятное дополнение. Покупают-то их не из-за этого.
Я думаю, не стоит считать заказчиков и их айтишников за дураков, которым вы открываете глаза. Может, они и дураки, но вы сейчас скорее толкаете их на ошибки. И без того многие считают, что смогут сделать свою крутую СЭД (или КИС) на Sharepoint а потом горько жалеют о своей недальновидности (я лично знаю несколько таких примеров).
Просто попробуйте как-нибудь потестить серьезное решение вроде XXX for Sharepoint или XXX Docs прежде чем обвинять компании в недобросовестном выманивании денег, и я думаю вы поймете, что я имею в виду.
я не пойму, с чем вы спорите.
в статье же ясно написано, насколько в родном Sharepoint (Foundation) бывает сложно разработать высоконагруженное решение.
а все остальное — о том, как это можно обойти.
И еще один момент, который, вы, возможно, не учитываете.
СЭД — это не портал. Принципы разграничения прав не по элементам, а по карточкам документов, например. То же самое и при отображении. Документ в СЭД — это же не просто элемент в списке или библиотеке, это элемент, связанный с кучей всего, вроде связанных файлов, других документов, журналов, поручений (которые еще связаны с задачами). Принципы работы довольно сильно отличаются. XXX for Sharepoint нужны как раз для адаптации Sharepoint к российскому документообороту, чего из коробки никак не сделать.
1) Согласен, но это справедливо, когда речь идет об универсальном решении. Если речь идет о СЭД (довольно узконаправленное решение), которая работает только через веб-интерфейс, проблемы нет. Вообще это вопрос не принципиальный. от себя могу добавить разве что использование ресиверов имеет много подводных камней, некоторые из которых далеко не логичны.
2) В Server — возможно. В Foundation попробуйте идексацию настроить) Кроме того не рид-онли доступ, данные меняются в базе при изменениях в списке, через ресиверы, например. БД и приложение-служба нужны для быстрого доступа к данным.
Чтобы ответить на ваш вопрос, приведу конкретный пример:
Государственный университет в регионе N хочет себе СЭД, пользователей на 100. Кроме СЭД хочет простенький портал, телефонную книгу, новости, календарики.
На Sharepoint Server денег тратить не хочется, да и нет необходимости — рейтинги, социальные сети, политики хранения контента не в почете у сотрудников.
Поэтому решили купить СЭД на Foundation, заплатив только за СЭД-надстройку (будем считать что лицензионные права на Foundation у них уже есть).
За 2-3 года документов скопилось около 60-80 тыс. (по всем группам). По ним нужно, в самом простейшем случае:
а) осуществлять быстрый и легко настраиваемый поиск (по конкретным атрибутам и без управляемых метаданных) по любым элементам и с учетом прав
б) быстро искать и исполнять задачи. задач при этом становится = (кол-во документов * 5)
Если знаете способ реализовать это на Foundation «изкаропки», пожалуйста, расскажите, очень интересно.
Затем, чтобы не путаться в своих многочисленных поручениях и действительно контролировать, а не искать изменения\удаления в списках. Нигде не видел, изначально хотел чтобы подобное допилили на Exchange.
Кому нужно будет, разберется.
Давайте спорить не будем — видимо вы встречаете одних заказчиков, а я других.
Про поле не совсем так, не упрощайте, и обратите пожалуйста внимание на строку «в самом простом случае».
Ок, мы выяснили, что какое-то решение на Sharepoint Server может оказаться дешевле чем тяжелая кастомизация на Foundation, при наличии нормальных спецов и четком понимании, что нужно сделать (не применительно к статье). Если выгоду измерять деньгах — без вопросов, такое возможно.
Другой вопрос, насколько это решение будет соответствовать функциональным потребностям и насколько им можно будет пользоваться (выгода от практического применения).
Как я понял, о чем разговор сейчас:
Вы говорите «сделать самим дешевле, продавцы СЭД на Sharepoint вас, как правило, накалывают», я говорю «нет, не накалывают».
Чтобы не быть голословнымм, приведу несколько (далеко не все) востребованных функций СЭД, которые сложно реализовать в шарике из коробки, и для которых в коробочных СЭД есть кастомизации:
1. Поля типа «расширенный лукап». Не стандартный лукап sharepoint (который не слишком удобен), а нормальный такой контрол, позволяющий искать подходящие организации (например) по инн, e-mail и на лету добавлять новые. Полезно при регистрации входящих писем.
2. Разграничение прав по полям. Особые права, например, требуются для поля «рег. номер».
3. Сложное (и быстро работающее, без потолка в 50 000) разграничение прав доступа. Не просто с наследованием от родительского элемента, а с многими хитрыми дополнениями.
4. Легко настраиваемые РП согласования, с возможностью запуска доп. согласований, условий, циклов, настройки прав на каждом этапе. Без Sharepoint Designer, в котором, даже для создания простого РП потребуется понимание того, что же внутри системы происходит.
5. Контроль и иерархия поручений.
6. Единое и настраиваемое рабочее пространство с задачами из разных разделов и удобным исполнением, с предпросмотром документа из окна исполнения задачи. Интуитивно понятный интерфейс риббона и других окон. Что, кстати, особенно важно для заказчика.
Влегкую заточенный под СЭД Sharepoint Server продать ему вполне можно, вот только он быстро взвоет от того, что какие-то простые вещи ему приходится делать через одно место, а для доработки звать дорогого специалиста. А звать придется точно, потому что ни один заказчик не знает в точности, что ему нужно. Вообще думаю, вы согласитесь с очевидной вещью:
«Продуманный аналитиками, протестированный множеством пользователей функционал и интерфейс пользователя сложной информационной системы, в среднем, намного лучше чем качественная одиночная кастомизация продукта, изначально под предметную область слабо приспособленного»
И весь вопрос сейчас в том, что вы считаете, что шарик для СЭД норм, а я считаю, что шарик для СЭД нужно серьезно доделывать. Если согласны, давайте говорить по существу этого вопроса, не отвлекаясь.
По поводу сценария — попробуйте обновить решение на существующее семейство сайтов (накатив новый WSP с новыми ресиверами). У меня после такого приходилось проделывать танцы с Sharepoint Manager.
Знаю как минимум 2 примера того, как в крупном предприятии устали от задач в Exchange (нет контроля, слишком много свободы у исполнителя и т.д.). Это про коммерцию. Про госструктуры — бумаги много, но это вершина айсберга. Руководитель с айпадом и ЭЦП вместо бумажек, контроль, сложный поиск документов, номенклатуры дел. межведомственный документооборот вы как будто не учитываете.
Покупают не только потому, что продажник ушлый(хотя и это бывает), а потому что во всем этом есть потребность.
другие статьи вашего блога читаю с большим интересом уже давно.
1. Да, Sharepoint Server классный, да там можно чудеса делать, но, повторю, настоящий российский документооборот с нормальным юзабилити и необходимым набором функций написать на нем стоит очень и очень дорого. Любому, кто представляет себе, что такое современная российская СЭД, ясно, что 16 часов — это фантастика. Даже для специалиста такого уровня как вы. Если нужно, могу аргументировать подробнее (о том, для чего все же приходится писать кастомизации).
2. Неясно, откуда вы взяли скидку в 90% для гос. ВУЗов.
3. Вы почему-то считаете стоимость времени разработчиков, хотя из статьи ясно, что речь идет о тиражируемом решении. Его установка, как правило, даже практически не требует усилий разработчиков и специалистов по Sharepoint.
4. Вы делаете акцент на доработках вроде создания приложения-службы и собственной БД как поводе для покупки. В XXX for Sharepoint это скорее приятное дополнение. Покупают-то их не из-за этого.
Я думаю, не стоит считать заказчиков и их айтишников за дураков, которым вы открываете глаза. Может, они и дураки, но вы сейчас скорее толкаете их на ошибки. И без того многие считают, что смогут сделать свою крутую СЭД (или КИС) на Sharepoint а потом горько жалеют о своей недальновидности (я лично знаю несколько таких примеров).
Просто попробуйте как-нибудь потестить серьезное решение вроде XXX for Sharepoint или XXX Docs прежде чем обвинять компании в недобросовестном выманивании денег, и я думаю вы поймете, что я имею в виду.
в статье же ясно написано, насколько в родном Sharepoint (Foundation) бывает сложно разработать высоконагруженное решение.
а все остальное — о том, как это можно обойти.
СЭД — это не портал. Принципы разграничения прав не по элементам, а по карточкам документов, например. То же самое и при отображении. Документ в СЭД — это же не просто элемент в списке или библиотеке, это элемент, связанный с кучей всего, вроде связанных файлов, других документов, журналов, поручений (которые еще связаны с задачами). Принципы работы довольно сильно отличаются. XXX for Sharepoint нужны как раз для адаптации Sharepoint к российскому документообороту, чего из коробки никак не сделать.
2) В Server — возможно. В Foundation попробуйте идексацию настроить) Кроме того не рид-онли доступ, данные меняются в базе при изменениях в списке, через ресиверы, например. БД и приложение-служба нужны для быстрого доступа к данным.
Государственный университет в регионе N хочет себе СЭД, пользователей на 100. Кроме СЭД хочет простенький портал, телефонную книгу, новости, календарики.
На Sharepoint Server денег тратить не хочется, да и нет необходимости — рейтинги, социальные сети, политики хранения контента не в почете у сотрудников.
Поэтому решили купить СЭД на Foundation, заплатив только за СЭД-надстройку (будем считать что лицензионные права на Foundation у них уже есть).
За 2-3 года документов скопилось около 60-80 тыс. (по всем группам). По ним нужно, в самом простейшем случае:
а) осуществлять быстрый и легко настраиваемый поиск (по конкретным атрибутам и без управляемых метаданных) по любым элементам и с учетом прав
б) быстро искать и исполнять задачи. задач при этом становится = (кол-во документов * 5)
Если знаете способ реализовать это на Foundation «изкаропки», пожалуйста, расскажите, очень интересно.