Exploring Guided Sourcing Full Project Template Attributes

Full Sourcing Projects utilize the same architecture as project workspaces,​ which is a collection of information, supporting project documents, events, tasks, and a team of users who can assist with duties within SAP Ariba Strategic Sourcing projects, all contained within a single workspace.

Full Sourcing Project Templates are used to:

• Standardize project creation by controlling what steps are included and what is expected of all users within an organization.
• Model an organization’s best practice process and may have unique company sourcing phases and tasks to track online and offline activities.
• Store one or more standardized project documents and event placeholders to run RFIs, RFPs, and auctions within the full project.

​​SAP Ariba Sourcing provides customers with a single, standard full sourcing project template for guided sourcing projects. Template Creators can find this template within the Sourcing folder via Manage→Templates.

​This template is designed to be customized and incorporate a company's specific sourcing procedures and workflows, capturing documents and activities within the various tabs of the full project container. New customers deploying SAP Ariba Sourcing will customize this template with their configuration leads, as it is a deliverable specified in deployment descriptions and customer contracts.

Full Sourcing Project Templates have the following tabs:

• Overview is where the template information is found, such as the Name, Owner, Rank, Access Control, and any Conditions that are applied to the entire template.

  

• Documents is where all of the sourcing initiative's documents and files are stored. Folders can organize multiple documents and have tasks or conditions applied to them. Event placeholders, PDFs, Microsoft Office files, template helper files, d-forms, savings forms, and reports are commonly stored in this location. It is common to have tasks associated with these documents, so they are completed in a particular order. Below, the Sourcing Event document is the most critical document, as it serves as the placeholder for the event and opens the event builder, where rules and content are created. In addition, there are example files; the Project Charter and Results Presentation. These are encouraged to be removed or repurposed, as they are visual samples of documents that can be integrated into a customer's workflow.
• Tasks is where the customization of the sourcing workflow activities takes place. All required tasks must be completed, as indicated by the red asterisks. Most tasks are to-do types that serve as checklists for offline tasks or provide instructions to the task owner on activities to perform. If a document is associated with a to-do task, it must be opened and edited before the task can be marked as completed. Project Owners are primarily responsible for executing the tasks within this tab, including creating and conducting the sourcing event. Customers are encouraged to remove phases and tasks that do not apply to their specific needs, and streamline their workflow by focusing on only the more critical, required activities. Companies can also add any new phases or tasks to incorporate company-specific protocols and business requirements through a series of task-driven activities.
• The Team tab is where project template groups and members are created and assigned. Template creators add new project groups so that they can be assigned as task owners, approvers, watchers, or team graders. Template Creators also have the option to specify if the project owner can edit the group or if it is locked to them for editing. Project groups can have static members or dynamic members by configuring Team Member Rules files. The default Project Owner group cannot be removed, as it specifies the creator and editor of the project. The Surrogate Bidders group should also remain in all templates for situations when surrogate bidding is required by SAP Ariba Auction Administrators and Market Integrity Specialists.
• Conditions is where a Condition, or Question can be created and defined. Conditions are often based on project header fields, where questions are manually keyed with potential responses. The labels and names of the conditions can then be applied to tasks, documents, and dynamic aspects of a project that depend on the answer to a question or the value of a field.
• Advanced Options is where Document Process Settings, Custom Actions Menu Settings, and Insight Tiles can be created. (These features will be detailed in a later lesson).
• History is an audit log of the template that captures all activities and modifications with time stamps and details.

• Full Sourcing Project templates capture sourcing tasks and processes in the workflow of a project workspace, ensuring consistent creation and compliance.
• Templates enforce required tasks and approvals, pre-populate team members, and provide essential documents for projects, including events within full projects
• There is one standard template for Full Sourcing projects that is configured during a customer's deployment.
• Full sourcing project templates have Overview, Documents, Tasks, Team, Conditions, Advanced Settings, and History tabs.

Let's quickly recap what we have learned in ARX280 Managing Project Templates about the key functionality of template conditions:

• When a user begins creating a full sourcing project, the system checks the project header field information and displays templates that define the remainder of the project structure. This is based on conditions within each template to match field values or answers to the user's questions.
• Template Questions appear beneath the full project template name and require input from the project owner. The answers to these questions are labeled and then applied to full sourcing project components, so their visibility depends on the answer.
• Once the template is selected, the appropriate content is added based on the template made available for selection. This includes the team, tasks, and documents, resulting in a consistent workspace containing all necessary information.

Template Administrators who are developing their company's full sourcing project template will want to collaborate with their company's sourcing process experts to identify which questions or conditions they wish to use to position tasks, documents, and event templates within the full project template container.

Some of the considerations for developing conditional content within sourcing full project templates include:

• How many full project templates should be visible? Some companies have more complex strategies than others, which require fewer tasks. Therefore, they choose to have a robust task workflow in one template for newer initiatives and a separate, streamlined template with fewer tasks and required steps. Consider using a template question to probe how much analysis and project work needs to be included, and display sections based on the answer.
• Which event templates are the most important or commonly used? Do all event templates align with our business strategies, or are there some considered extras that we can inactivate to reduce clutter in our production realm? Which event templates should be embedded as placeholders in our full project template?
• Does our template have redundant task activities or unnecessary approvals? Templates should automate project creation and save time; therefore, keep them simple and remove any unnecessary elements or features that will not be used.
• How experienced are our project creators? Are directives required to provide guidance and helpful text within the task descriptions to facilitate next steps or help them navigate the project? What types of events are they mostly running and which templates do they select? How can I make things easier for their project creation responsibilities?