none
Какую структуру/архитектуру выбрать для крупного портала? RRS feed

  • Вопрос

  • Доброго времени суток.

    Стоит задача организации корп. портала на базе SP13 Srv.
    Но есть ряд "но".

    1. Нужно организовать документооборот
    2. Нужно организовать постановку задач
    3. Нужно организовать создание и контроль над заявками

    Все просто, а нет.

    В организации есть ряд дочерних предприятий ( один лес, если что ).
    Куча отделов. У каждого из отделов :

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

    И вот теперь вопрос : Как лучше организовать архитектуру в плане суб-сайтов?

    Пока вижу пару вариантов :

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

    2. Разбить по организаиям и отделам
    Тут же сталкиваемся с "межсайтовым" (не)взаимодействием. Т.е. "кастомных" разработок получится больше, чем самого sharepoint'a. Или я не прав? Придется делать кросс-сайтовые указатели и, в случае необходимости ( а она будет повсеместно ) - писать самим отображения списков дабы их представлять на других сайтах.

    В целом буду крайне признателен за дельный совет из серии "в какую сторону лучше смотреть" ну или примеров хороших :)

    Спасибо за внимание.

    22 октября 2014 г. 14:40

Ответы

  • Не так.

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

    Никаких кросс-сайтовых лукапов, используйте таксономию.

    Чтобы не пойти в неверном направлении надо сконцентрироваться на решаемых проблемах, а не на структуре.


    Business Solutions Architect, SharePoint Expert, Trainer, Speaker and Author http://gandjustas.blogspot.com/ Join Russian SharePoint Community at https://www.facebook.com/groups/sharepointrussian/

    24 октября 2014 г. 17:52

Все ответы

  • Разбить по отделам, смотреть лучше в сторону поиска и content search webpart.


    Business Solutions Architect, SharePoint Expert, Trainer, Speaker and Author http://gandjustas.blogspot.com/ Join Russian SharePoint Community at https://www.facebook.com/groups/sharepointrussian/

    23 октября 2014 г. 5:30
  • Разбить по отделам, смотреть лучше в сторону поиска и content search webpart.


    Business Solutions Architect, SharePoint Expert, Trainer, Speaker and Author http://gandjustas.blogspot.com/ Join Russian SharePoint Community at https://www.facebook.com/groups/sharepointrussian/

    А как лучше поступить с совсем уж "общими" направлениями?

    Т.е. мы получаем иерархию сайтов для отделов + личный кабинет (у нас не Foundation). У них там свои документы, задачи и пр. Т.е. они вобщем то изолированы. Но отсаются такие направления как, скажем, договора. Их инициируют все отделы, по логике сами библиотеки мы запихиваем в отдел документооборота. Но как лучше организовать централизованное с ними взаимодействие? "Хождение по отделам" для пользователя не очень приветствуется. Есть ли каке-то примеры?

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

    С общими справочниками все проще - просто делаем кросс-сайтовые lookup'ы и ок. Так?

    p.s.

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


    • Изменено IanRy 24 октября 2014 г. 8:53
    24 октября 2014 г. 8:52
  • Не так.

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

    Никаких кросс-сайтовых лукапов, используйте таксономию.

    Чтобы не пойти в неверном направлении надо сконцентрироваться на решаемых проблемах, а не на структуре.


    Business Solutions Architect, SharePoint Expert, Trainer, Speaker and Author http://gandjustas.blogspot.com/ Join Russian SharePoint Community at https://www.facebook.com/groups/sharepointrussian/

    24 октября 2014 г. 17:52
  • Согласен конечно, но получается и сайты, скажем, документооборота и саты отделов, и сайты заявок и сверху личный кабинет. Люди одуреют от этого. Привыкли к единому рабочему пространству ( была раньше СЭД "Мотив" - гадость та еще кстати ).
    27 октября 2014 г. 8:38