JANUARY 2014
1 Introduction (3)
2 Before You Begin (6)
2.1 Defining Your Strategy (6)
2.2 Building Your Team (7)
2.3 Choosing Your Partner (10)
3 Feasibility Phase (12)
3.1 Feasibility Phase Tolls (13)
4 Foundation Phase (14)
4.1 Getting Started (14)
4.2 Project Kickoff (15)
4.3 Organizing and Staffing (15)
4.4 Goal Setting and Planning (17)
4.5 Team Training (18)
4.6 Multi-channel Accelerators (19)
4.7 High Level Architecture (19)
4.8 Create Infrastructure (Development Setup) (22)
4.9 Requirements Reviews & Workshops (23)
4.10 Foundation Phase Tolls (24)
5 Exploration Phase (25)
5.1 Product Data (26)
5.2 Search (31)
5.3 Omni Channel Commerce (32)
5.4 Prices, carts and checkout (36)
5.5 Commerce Integration (38)
5.6 Fulfillment process (38)
5.7 Solution architecture (38)
5.8 Reporting and Analytics (39)
5.9 Backend Systems (40)
5.10 Architecture Reviews & Workshops (40)
5.11 Exploration Phase Tolls (40)
6 Engineering Phase (41)
6.1 Architecture (41)
6.2 Local Environment (42)
6.3 Software Design (43)
6.4 Development (43)
6.5 Data (45)
6.6 Code
Review (45)
6.7 Documentation (45)
6.8 Testing (46)
6.9 Data Migration (47)
6.10 Monitoring (47)
6.11 Engineering Phase Tolls (48)
7 Deployment Phase (49)
7.1 Production Cutover Planning (49)
7.2 System Maintenance (50)
7.3 Training (50)
7.4 Go Live - Execution (51)
7.5 Debrief (51)
7.6 Deployment Phase Tolls (51)
8 Support and Operations Phase (52)
8.1 Monitoring (52)
8.2 Contacting hybris Support (52)
8.3 Incident and Problem Management (53)
8.4 System Maintenance (53)
8.5 Change and Release Management (53)
8.6 Documentation (53)
8.7 Support and Operations Phase Tolls (54)
9 Typical Project Pitfalls (55)
9.1 Business requirements not fully supported by the platform (55)
9.2 Overlooked functional areas (55)
9.3 Very large functional requirements (55)
9.4 Premature Go Live (55)
9.5 Recommended order of design activities (56)
R O J E C T B E S T P R A C T I C E S
1. INTRODUCTION
Congratulations on your selection of hybris software!
hybris was founded in 1997 with a simple mission: to create superbly engineered commerce solutions. Over the years, what that means has evolved—multichannel, open standards, high performance, data centricity, customer centricity—and so our company and products have adapted. But our mission has remained the same. We are, above all, a great commerce technology company. hybris Professional Services has been working with customers and partners to design and implement solutions based on hybris technology.
You are in good company. We now serve over 500 customers, including some of the most recognized companies in the world (global B2B brands as well as consumer brands). We are now by far the fastest-growing major commerce platform company—our compound annual growth rate since 2009 is 83%.
As much as we are a company built on better technology, we are also a company built on a philosophy of partners and a culture of innovation.
From the beginning, we have relied on partners who are deeply knowledgeable in their industry specialties and very close to our customers to lead most implementations. We can now count among our 200+ partners some of the most widely respected names in the industry, around the globe.
To compliment our partner ecosystem, hybris’ highly skilled Professional Services consultants deliver pragmatic advice and guidance, helping leading brands, manufacturers, and retailers to maximize the value of their multi-channel programs by effectively balancing function, time to market, and expected return on investment. Adding hybris Professional Services to your project allows hybris to have a “seat at the table” and help ensure your success and best practices with the implementation of hybris software. We are committed to the following:
? Shaping your multi-channel vision by understanding the true potential that multi-channel holds for your company ? Appraising your current situation and identifing the blockers and enablers for multi-channel in your organization ? Planning your approach with a roadmap that will help you achieve your multi-channel goals
? Realizing your plans and helping you deliver the multiple programs and projects required, on time and on budget ? Growing your revenue and profits and uncovering ways to improve and expand your multi-channel business
What to expect
This document provides a summary of hybris project best practices as collected by the hybris team responsible for project delivery. The main intention of this document is to provide the reader with “a set of activities an implementation team should consider during a hybris commerce project implementation”. The target audience includes:? Project managers, to better understand recurring specific hybris e-commerce project activities, their dependencies and timing ? Architects, to better understand typical recurring design considerations
? Business consultants, to get a better idea of mapping of general e-commerce functionality requirements
R O J E C T B E S T P R A C T I C E S
? Team leaders and scrum masters, to be able set up and run hybris project in an optimal way ? Project owners, to have a better insight what a typical hybris project consists of
The following topics are beyond the scope of this document; however direct conversations with our Professional Services team will advise you:
? Development methodology, team structure or communication style. Our extensive partner network provides expertise on building a project approach, staffing model and timeline that is right for your specific requirements.? Specific and deep project answers to architectural, design or technical questions. The document does provide general guidelines and considerations, but specifics often differ from one project to another. Only a deep understanding of requirements, technology and available scope of work lead to an optimal solution in each individual case. We are committed to keep extending our knowledgebase on our wiki where specific knowledge sharing happens.? This document is bound to hybris technology, but is not bound to any specific hybris software version. Some functionality changes from one version to another. This document is under continual improvement—with future version releases expected. So please always ask for the latest version.
Document Structure
The document is structured into the following chapters:
Each chapter describes typical activities in each individual phase. The phases themselves should be seen as building blocks and can be used repetitively with both agile as well as waterfall development methodologies.
hybris Toll Gates
To help prepare you for your implementation and to avoid common project pitfalls, hybris Professional Services has introduced the concept of hybris implementation “Toll Gates.” Every implementation team faces time pressure and technical challenges, but in our experience the most common and obvious difference between successful
implementations and those “at risk” can be traced to skipping steps or failing to validate work at the right point in the implementation. A roadmap with a highlighted trip route is a good analogy for project plan and timeline documentation. Toll Gates take this analogy one step further by recommending the placement of virtual gates in the project plan/
timeline where teams check to ensure they have completed the work (paid the tolls) to ensure project success before they move on. Some of these tolls are as simple as confirming check list tasks have been completed, while others may involve special implementation tasks in themselves which, when performed correctly and at the right point in the implementation, can save costly rework, delays and frustration.
Of course, it is tough to perform or validate work if you don’t know what to look out for. hybris Professional Services has prepared this series of recommended Toll Gates and Tolls based on industry best practices and past project experience. hybris clients and partners are encouraged to adopt, modify and expand on this list to suit each implementation project. Gates align with each phase of the implementation and one or more “tolls” need to be “paid” prior to moving to the next phase. Paid tolls should be documented and acknowledged while unpaid tolls should (of course) be escalated and addressed during project status and/or steering meetings. In this document, each section will end with its corresponding “tolls,” marked as [[T]].
R O J E C T B E S T P R A C T I C E S
About the authors
This document was created and is maintained by hybris Professional Services. We have worked with hundreds of
customers to successfully implement hybris software, and we help our partners and customers with everyday project tasks. hybris Professional Services is here to:
? Enable you to implement hybris projects better, faster and with confidence ? Provide real life experience from many projects
? Provide best practices and service programs to make projects successful
? Augment your project team where needed (reviews, specific customizations, integrations, etc.)? Provide a “hybris recommendations filter” on your implementation
The content of this hybris Project Best Practices guide is highly confidential and the conditions of the confidentiality agreement strictly apply. This guide is for informational purposes only and must not be disclosed to anyone and/or forwarded or copied in any way or form. The hybris project best practices and the information contained in this guide may be subject to change, updates, revisions, verifications and further amendments by hybris at any time without notice.While the information contained in this guide has been prepared in good faith, neither hybris nor its shareholders, directors, officers, agents, employees, or advisers give, has given or has authority to give, any representations or warranties (express or implied) as to, or in relation to, the accuracy, reliability or completeness of the information in this paper, or any revisions thereof, (all such information being referred to as “information”) and liability therefore is expressly disclaimed. Accordingly, neither hybris nor any of its shareholders, directors, officers, agents, employees or advisers take any responsibility for, or will accept any liability whether direct, express or implied, contractual, tortious, statutory or otherwise, in respect of the accuracy or completeness of the information or for any of the opinions contained in it, or for any errors, omissions or misstatements or for any loss, howsoever arising from the use of this guide. In furnishing this guide, each of hybris and its advisers does not undertake or agree to any obligation to provide the recipient with access to any additional information or to update this guide or to correct any inaccuracies in it, or omissions from, this guide which may become apparent.
R O J E C T B E S T P R A C T I C E S
2. BEFORE YOU BEGIN
Setting your hybris project up for success before you begin implementation—Are you ready?
The amount of complexity to implement the hybris commerce suite should not be underestimated. A surprising number of e-commerce implementations begin without clearly defining the organization’s vision for a successful outcome and who is going to be involved (and when). These organizations are simply not ready to begin. Typically, they lose weeks or months resetting expectations, redefining their projects and addressing the frustrations of their stakeholders. Sometimes they run out of time or other resources and end up going live with less than they hoped. This can be
avoided; there is work to be completed before the implementation can begin. Given the amount of time and money your organization will be investing, hybris strongly recommends starting your project with the best possible foundation of vision and resources. Before you begin, take extra time to ensure three pieces are in place:
1. Company Strategy: First, identify what the organization needs to achieve then define specific expectations around how the hybris implementation will impact and benefit these strategic objectives.
2. Company Team: Identify responsibilities for technical and business stakeholders during the implementation, and consider changes to roles, skills and responsibilities (org. structure) post implementation.
3. Partner of Choice & Partnering Strategies: Even the best partners and the greatest clients can be miss-matched. Define what is important to your organization and be ready to share it with your partner(s).
By ensuring these have been defined and understood by your organization, you are on the way to preventing some of the common pitfalls we have seen while undertaken a hybris project.
2.1 Defining Your Strategy
Having a clear strategy is one of the most important ways to ensure a successful project. Strategy needs to be
defined in terms of expectations of success and shared with the implementation stakeholders so there is a common understanding and motivation. hybris Professional Services have been brought into “off the rails” projects only to discover it was never clearly defined what was trying to be accomplished or what defined success. Again, these organizations were not ready to begin.
Every organization should start with an overall vision, which can be company-wide or commerce-specific. A good
practice is to validate that your team shares an easily understood top-level strategic goal, typically one or two sentences long, that stakeholders should be able to communicate regardless of their role. From there, you can drill in to more department specific goals, prioritize them, and define their success criteria. Whenever possible, define measurable success (and Return on Investment) by setting revenue targets, measuring baseline metrics, and identifying KPIs. Additionally, leading change is essential and often overlooked aspect of many software projects. There are many moving pieces to a commerce implementation and each piece can require new skills and impact people and roles. Regardless of your organization’s philosophy on change management, it’s a good practice to communicate what you know (and don’t know) early and often. Focus first internally on the people, process, and technology - ensuring everyone in the
organizations knows what you are driving towards and how you will get there. Other proven practices for leading change include: demonstrating strong leadership, communicating early and often, and training/educating throughout the
R O J E C T B E S T P R A C T I C E S
Here is a list of recommended Before You Begin questions to help assess if your organization is ready to begin planning a hybris implementation:? What is your vision?
? Who are your key stakeholders?
? What are your project’s goals and objectives?? What will define success?? What are your pain points?
? Do you have any target metrics or KPIs?? What is your change management strategy?? Does your organization have the required skill set?? Have your requirements been documented?
Finally, hybris also recommends having an organizational strategy around Intellectual Property (IP). Every hybris
implementation has unique and often very innovative elements specific to the organization, often related to the strategy. hybris recommends having a complimentary IP strategy for documenting and preserving your work, for example where your code will live and how it will be maintained. hybris sees many organizations become tied to their partner or system integrator because they don’t have a long-term maintenance and preservation strategy. Regardless of where you environments will live, it is strongly recommended to have a copy of your code internally, as well as a resource to maintain it.
2.2 Building Your Team
Next to strategy, your people and internal team structure is the second important factor when undergoing a commerce project. It’s a very common project pitfall to begin a hybris implementation before adequately predicting requirements of new skills and new roles both during the implementation and again as the organization shifts from construction to go-live to operations. Avoiding this requires predicting business and technical skill requirements and role impacts before you begin your implementation, and building your business and technical teams accordingly.
hybris specialists are often asked, “What’s the best practice requirement staffing requirement our new omni-commerce solution?” It can be difficult to calculate the number of staff required for your e-commerce team, both during implementation and for live operations. According to published industry surveys, three quarters of online retailers have more than three employees devoted to e-commerce. For an omni-channel organization running hybris, many essential business functions are shared across all channels. Product sourcing, creative, human resources, accounting and even some fulfillment responsibilities are shared with brick-and-mortar and catalog channels. In this environment, it is important to understand the essential roles that make up the e-commerce team.
While there is no easy “best practice staffing level” recommendation for hybris or any commerce solution, we do know that 75% of e-commerce sites require at least three staff members. So unless your site is very small, filling the essential e-commerce roles (marketing, merchandising and operations) with dedicated FTEs should be your bare minimum level of staffing. Better staffing predictions can be made by evaluating common variables should help guide your staffing decisions:
E-Commerce Marketing
? How frequently do you send out emails?
? How frequent are your site promotions? Do you have web-only promotions?? Do you have or plan to have affiliate programs?? Will paid search be managed internally or by a vendor?
R O J E C T B E S T P R A C T I C E S
E-Commerce Merchandising
? How many products are you selling online?? How often do those products change?
? What is the quality of the product data you receive? How much rework is needed?
? Do products have a natural categorization and association (cross-sells), or is intervention required to build categories and associations?
? How dynamic is your inventory? Do you have products that are frequently out of stock and not available for purchase?
E-Commerce Operations
? How much of the site development is being done in-house vs. outsourced?? How many vendors do you need to manage?? How complex is the site?
Predicting staffing levels for the implementation team is even more difficult and driven by many variables such as build complexity, experience and timeframe. Just as strong leadership starts from the top down, successful teams are built in the same fashion. Traditionally, this falls into three groups: business, IT, and operations. Organizations should begin mapping out which roles will exist in-house, and which will be done through a third party. This will typically be related to the deployment model of the solution, specifically whether it will be on-premises or hosted. Once this has been determined, you can determine which roles need to be created and establish a hiring plan from there.
At a minimum, hybris recommends accounting for the following roles. Note: Many of these roles are not full-time positions, and are often combined and performed by single individuals.
BUSINESS
RO L E DESCRIPTION
Marketer Responsible for generating email campaigns, promotions, and sales.
Merchandizer Responsible for relationships between products, particularly for cross-selling and up-selling.Content Manager Responsible for managing and approving site content.
Graphic Designer R esponsible for creating the media content that is displayed on the site, particularly images and video, it may or may not also include HTML and CSS.
Payment & Fraud Responsible for ensuring the books are balanced, and monitoring and preventing fraud.Analytics & Business
Specialist role that analyzes site data, and monitor customer behavior for optimization. Intelligence Specialist SEO Specialist Specialist role responsible for maximizing search exposure and results.
Translator
Responsible for translating the content when the site is available in other languages.
IT
RO L E DESCRIPTION
Operations Manager
I n charge of the day-to-day technical operations of the site, support, and IT. They are primarily
R O J E C T B E S T P R A C T I C E S
Developer M ay be skilled in one or more of Java, HTML, CSS, and JavaScript. An in-house resource can be useful for making day-to-day changes to the site and small to medium feature changes.Database Admin A
n optional resource, person skilled in SQL for operation, maintenance, and support of the database and its underlying technology.
Network Admin R esponsible for operating, maintaining, and supporting the network. This includes servers, fi rewalls, switches, and routers.
Technical Support
F irst level of technical support for the site, they address day-to-day issues and provide
assistance to internal and external users. Should a severe problem or error occur, they would likely escalate to one or more of the above roles.
OPERATIONS & SUPPORT
RO L E DESCRIPTION
On-line Store Manager R esponsible for the day-to-day operations of the site, including managing products, pricing,
and promotions.Support Team Lead R esponsible for managing the CSR team, dealing with escalations, and ensuring issues are resolved in a timely manner.
CSR C
ustomer Service Representative who would be responsible for handing in-bound customer calls and emails.
Purchaser
I
n situations where the organizations does not manufacture their own goods or sells third party products, this role works with suppliers to source and order product.
Warehouse Manager I n charge of the pick/pack staff, they are responsible for the day-to-day operations of the warehouse and ensuring shipping service levels are met.
Picker/Packer
W
arehouse personnel who are responsible for receiving and shelving inventory, counting stock, and picking, packing, labeling and shipping individual orders.
2.2.1 SAMPLE ORGANIZATIONAL STRUCTURE
The diagram at right outlines the typical roles necessary for a B2C commerce
Implementation.
R O J E C T B E S T P R A C T I C E S
2.3 Choosing Your Partner
All organizations have a variety of technology partners. The third important factor to consider before you begin a hybris implementation is selecting your hybris implementation partners. Over 95% of organizations implementing hybris choose to collaborate with a technology partner specializing in hybris. hybris has an extensive and global
partner network, but experience has shown that even the best partners and the greatest clients can be miss-matched. Organizations implementing hybris software vary widely in what they value in a System Integrator (SI) and how they work with their technology partners. Likewise, partners vary significantly in size, style, and focus.
Knowing that carefully selecting a systems integrator is a critical step to a successful project, hybris is often asked to recommend partners or provide guidance on how to make the best selection. Of course, every customer must choose its partner according to its own internal criteria and selection process. Before you begin, hybris does recommend you define what is important to your organization and be ready to share it with your partner candidates, the following questions will assist this process:
? Do you have an incumbent agency / SI that you would like to work with?
? What range of service do you require? The typical services provided by partners are: strategy, design, program management, implementation and ongoing application support.? Would you prefer to work with a large consulting organization or a smaller boutique firm?? What other key technologies expertise is expected within the company? (ERP, Search, WCM)? Do you have preference for on-site versus remote delivery? What about off-shoring?? Where is the SI team located that will be involved with the implementation?? Do you have a preferred implementation methodology? (Such as Agile or Waterfall)
Below are recommended questions to ask when interviewing candidate hybris implementation partners:? Are they a hybris certified partner? (Gold / Silver / Bronze)? Are more than 40% of their developers hybris certified?
? Are the Team Details shared, including biographies and certifications?? Are the Architect and Team Lead hybris certified and experienced?? Have they delivered more than one hybris implementation?? Have they provided a valid reference?
? Do they specialize in your vertical market segment?? Can they staff your engagement within your timelines?? Can they share examples of how they document your project?
? Is their code quality criteria explained? Do they follow hybris recommended best practices?
2.3.1 RECOMMENDED PARTNER PROJECT TEAM
At the very minimum, hybris expects a partner to staff an engagement with the following roles. Individual partners may name the role differently, but their competency should be the same. Additional specialist roles may also be proposed to further augment the project team.ROLE
HYBRIS COMPETENCY
Executive Sponsor Particularly when hybris assigns an Exec Sponsor
Client Relationship/ Customer Care/Contract Role, works closest with hybris Account Manager Program Manager
R O J E C T B E S T P R A C T I C E S
Project Manager Required: hybris project delivery boot camp Business Analyst Recommend: hybris BA certification
hybris Architect Required: hybris certification Core & Commerce Development hybris Lead Developer Required: hybris certification Core & Commerce Development hybris Developer(s) Recommend: 40% of build team is hybris developer certified QA/Testing
Recommend: hybris BA Training &Core Developer
Some customers prefer to do all the development using internal resources and to not depend on partners at all.
However the typical feedback towards the end of these projects is, that at least some partner involvement would have been a better option.
2.3.2 PROJECT DOCUMENTATION
hybris expects that every partner project is formally documented, and if required, the partner will quickly provide:? Signed contracts with client and hybris-approved budget
? Project Governance “Rules of Engagement” is documented, especially ties to hybris Account Management, Managed Services, yServices, Support and Training, Escalations, Stakeholder roles ? Documented Requirements & Designs which can be shared with hybris as needed e.g. “Prioritized Scope Matrix”? Methodology/Approach (e.g. agile) must be documented
? Project Org. Structure including names, certifications of assigned resources ? Delivery Model Documented (Onsite vs. Offsite work, On-Shore vs. Off-Shore)? Infrastructure diagram/tools – Environments, Source Code Repository, Security ? Plans: e.g. Project Plan, Testing Plans etc.
? Project Status: Budgets consumed, remaining – work completed, effort to complete
? When undergoing the partner selection process, hybris recommends request samples from past partner projects.
R O J E C T B E S T P R A C T I C E S
3. FEASIBILITY PHASE
The feasibility phase is an evaluation and analysis of the potential of the proposed project, based on extensive investigation and research, to determine whether it is viable. It precedes the development and implementation phases.
Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of an existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry the project through, and ultimately the prospects for success. In its simplest terms, it’s an analysis of expected cost and expected value. As such, a well-designed feasibility phase should provide project background or context, description of the end result or desired result (including requirements for the ongoing operations and management), and financial data (cost and revenue expectations).
The feasibility phase evaluates the project’s potential for success; therefore care must be taken to deliver a balanced, credible review. The project stakeholders depend upon hybris to conduct this assessment with an objective, unbiased approach and to provide information upon which decisions can be based.
The assessment is based on an outline design of stated business objectives and technical system requirements, to determine best technology and process fit. This could include assessment of the technical expertise required to successfully complete the project and assessment of the likelihood that the proposed technical solution will support the business requirements. When writing a feasibility report, the following should be taken to consideration:? A brief description of the business to assess possible factor(s) which could affect the study ? The part of the business being examined ? The human and economic factors ? The possible solutions to the problems
At this point, the objective is to identify the facts that will help determine if the proposal is feasible from a technical and business perspective. Financial analysis may be included (e.g., breakeven analysis, EVA or other metric generally used by the customer to gauge project value).
Mapping this phase to the Project Management Institute (PMI) PMBOK project phases, the feasibility phase would overlap some of the activities in the initiating and planning phases. Some (not all) of the activities in this phase include:? Selecting a Project Manager ? Dividing large projects into phases ? Identifying stakeholders
? Documenting business needs, project objectives, assumptions and constraints ? Developing project charter and scope statement
R O J E C T B E S T P R A C T I C E S
The hybris pre-sales team assists your organization during your software evaluation and selection process in the following ways:
? Responses to RFI/RFP questionnaires ? Product demonstrations
? Gap analysis between business requirements and hybris platform features ? Software pricing estimates (based on volumes, number of servers, etc.)
? Implementation estimates (done in conjunction with a hybris implementation partner) ? Training estimates ? Maintenance estimates
Feasibility phase deliverables should provide enough information for the organization to be comfortable with the selection and purchase of hybris software, and can then be used as inputs to start the project. Information gathered from the feasibility evaluation should provide the basis of documented business requirements for the project.
3.1 Feasibility Phase Tolls
? Internal stakeholders have been identified
? Business needs and project deliverables have been documented ? Project budget has been proposed and approved ? Implementation partner has been selected ? hybris has been licensed
R O J E C T B E S T P R A C T I C E S
4. FOUNDATION PHASE
The purpose of the foundation phase
(sometimes known as the analysis phase) is to create an aligned scope and plan that the architecture team believes can be delivered.
It helps to define the scope and level of effort, and to demonstrate that there is a solution that will work. During this
time, the delivery team takes ownership of the project. The role of the Solution Architect is particularly key to the phase; while hybris delivers a set of functionality to the project, there is a need to find out how it will work with the customer’s existing technology solutions.
The foundation phase output will consist of:
? A Project Charter describing project organization, methodology, check points ? A Project Plan for the exploration phase ? High-level business requirements ? High-level technical documents
4.1 Getting Started
Start by ensuring that all prerequisites for a successful project are in place, the areas to cover are the following:? Key stakeholders are identified and contact information is available (this should include representation from the client, partner(s), as well as hybris): ?Project Sponsor(s) ?Project Owner(s) ?Project Manager(s) ?Account Manager(s)
? All legal documents are in place: ?Non-disclosure agreement ?hybris Master License Agreement
?hybris Customer Support Policy, including hotline support number ?hybris Master Services Agreement
?hybris Statement of Work (SOW) ? Project framework:
?Vision and Business goal, what is driving this project ?Project Methodology – (e.g., waterfall or agile) ?Communication/project status plans ?Project assumptions
R O J E C T B E S T P R A C T I C E S
4.2 Project Kickoff
A project kickoff meeting should be set to create a plan outlining how to organize the foundation phase. At the end of this phase the team must be established and aligned with the business goals. In more detail:
? Roles have to be established. The team structure and reporting lines need to be created across all involved parties (project owner, hybris, implementation partner), and during the project kickoff, team members will be assigned to the various roles. ? Each team member needs to understand their role, when they will start participating on the project, and how much of their time will be allocated. Whoever was responsible for assigning the right people to the project during project kickoff will now need to proactively manage the involved team members and their participation during the project itself. ? Define who will create and maintain the Project Plan. There are three dimensions to every project: time, cost, and feature set. While any two dimensions can be easily managed, the remaining third dimension could potentially spin out of control. The Plan should prepare for such situation, and prioritize the dimensions.? Communication channels should be discussed as well. What will we use in everyday communications? Where will the issues be tracked? Who to call in case of urgency? The goal of the kickoff meeting is to find the responsible owners of all these decisions for all parties involved.The meeting should also reconfirm the already set strategic business goals, and make sure everyone on the team members understand them.
It’s also important to identify and discuss all risk factors and make somebody responsible for risk mitigation. The risk factors differ from project to project, but these examples could serve as a good starting point:? Team members are not confirmed for the project yet ? Unclear or undocumented business requirements ? Lack of understanding of software capabilities
? Team member expertise does not correspond to the expertise required by the role ? Unclear ownership and responsibilities ? Missing or insufficient technical infrastructure ? Missing or wrong key performance indicators
? Working from multiple locations, across multiple time zones ? Pressures outside of the project
? External dependencies on other parallel project(s)
4.3 Organizing and Staffing
As discussed in project kickoff, a well-established team is key to the project’s success. Every project team is organized differently, however most teams include one or more of the following:
? Project Manager: responsible for coordinating the whole project externally and internally. Make sure the Project Manager is given the authority he/she needs—all others are stakeholders ? Business User Representative: responsible for detailed functional specifications and acceptance criteria ? Business Analyst: responsible for defining and facilitating functional requirements and understanding to the project team and stakeholders ? Solution Architect: responsible for the technical solution architecture and integrations
? Software Architect: responsible for software design, modules, design patterns, and use of hybris platform functionality
R O J E C T B E S T P R A C T I C E S
? Software Developers: responsible for software implementation, testing, and maintenance ? User Experience/UI Experts: responsible for ergonomics and usability of the solution ? Testers: responsible for implementing and running tests
? Content Providers: responsible for product content as well as site content—typically from the business ? Technical Experts, such as database administrators, system administrators, network administrators, or hybris experts as needed hybris Professional Services offers an example RACI document, which provides a matrix for typical activities on a hybris project. Each activity has assigned parties (customer, partner, hybris, third party), each party has an assigned role for each activity. The roles are: Responsible, Accountable, Consulted and Informed. hybris Professional Services can help you with creating the RACI document for your project. An example RACI document maintained by hybris managed services could be found on our wiki:
https://https://www.doczj.com/doc/7310939663.html,/display/MSS/Roles+and+Responsibilities+-+RACI
Some team members are on the project for its entire duration (for example Project Manager), while other members may join later (Quality Assurance), or leave early (Solution Architect). Some team members could be fully dedicated to the team (Application Developer), while others may work only part time (Subject Matter Experts). It is important to establish processes to ramp-up every new team member as fast as possible. It is similarly important to establish processes to document all the important knowledge if a member leaves the team to allow smooth transition.
Establishing internal and external communication processes is also key. Too many people involved in communication, attending meetings, and providing input results in slow progress and lack of accountability. On the other hand, lacking or poor communication leads to confusion around project goals, requirements, architecture, or API contracts. It is always important to fi nd the right balance for your specifi c project.We recommend overseeing the project progress by a Project Steering Committee. This Committee ideally meets at a minimum of every two weeks; a hybris Service Delivery Manager should be in attendance at these meetings. This is also a good time to establish policies, controls, and formalize the project organization. The project size is usually the most
important contributor to the level of recommended formalism.
R O J E C T B E S T P R A C T I C E S
4.4 Goal Setting and Planning
Once the team has been established, it’s time to focus on the project itself. The business owners should set-up and discuss high-level requirements. If the project moves an existing solution to a new platform the discussion should cover:
? Which existing features are essential ? Which existing features are nice to have ? Which existing features are no longer needed ? Which new features are essential ? Which new features are nice to have
? Which new and existing features can be modified to fit with existing hybris functionality In either case the discussion should cover:
? Do we want to maximize the initial feature set? This could make the project long and beyond budget constraints.? Do we want to deploy as soon as possible? This could make the initial feature set below expectations.
The discussion should not only cover functional, but also non-functional requirements, including performance requirements. There’s a huge difference between building a solution for 2000 orders/day and 2000 orders/second. Sometimes there can be a trade-off between functionality and performance.
The discussion should also cover all functional domains from the business point of view (commerce, data management, media management, order management, stock management, etc.). Very rarely are all the domains managed by one system. The business users will work with multiple systems, and technical people need to integrate them. It is too early to discuss individual details (such as individual features or integration patterns), but it should be clear what business processes will be modified, created, or become obsolete. Every Business User Representative should have a clear vision or at least an understanding of how his everyday work would be affected or improved.
Risk management should also be established in this phase. The risks uncovered in the kickoff meeting or during the project need to be managed in a structured and formalized way. This will not only minimize the risk, but also provide insight into what decisions were made to mitigate the risks and why. This could be a valuable source of information in later stages of the project if necessary.
Business users need to familiarize themselves with the capabilities of the software—especially the use of
hybris cockpits. There should be no surprises at the end of a project that pre-built hybris components do not meet the requirements of the business. hybris Professional Services provides business user workshops can help assist in this area.
The project team should accomplish the following tasks as a result of the initial project planning (also refer to the planning phase of the Project Management Institute project phases):? Initial drafts of high-level requirements
? Dates, participants, and timeline for completion of the requirements workshops & deliverable reviews ? Procedures for issue tracking, issue resolution, and change management
? Updated Project Plan
? Approval of the Project Plan from the Project Steering Committee
R O J E C T B E S T P R A C T I C E S
4.5 Team Training
Fundamental technology skills are required as the basis for hybris development teams, including: Java, Spring, SOLR, ZK framework, and Apache Tomcat. There are industry-training classes that can be leveraged to help your developers learn these skills.4.5.1 HYBRIS TRAINING
hybris Training is responsible for developing and delivering training programs for all hybris customers and partners. hybris has trained thousands of developers in hybris technology. To examine our standard training programs and offerings, please see our Academy training shop website at https://www.doczj.com/doc/7310939663.html, .hybris training offerings include:
? Instructor led Courses: hybris role-based curriculum is designed to address the needs of every member of your team - Business Managers, System Administrators, and Developers. Courses provide informative lectures and hands-on labs to maximize your experience ? Global training centers: students can attend courses at a variety of hybris training center locations, including Chicago, Boston, Munich, Paris, and London ? On-site training: a convenient and cost-effective way to train groups of students at the same time. On-site training provides the additional benefit of allowing the course delivery to be focused on your needs ? Web-based virtual classes: available for select courses
? hybris Certification: This program sets the standard for hybris knowledge within our customer and partner community. These web-based exams can be registered for and taken online at any time hybris courses include:
hybris Quick Start: a one-day, intensive training designed to give attendees a thorough introduction to the entire hybris platform and its extensions.
hybris Developer Training Part I - Core Platform: This four-day training has a 60/40 hands-on/lecture format, and leans heavily towards Java J2EE developers. All of the core functionality of the platform is covered, as shown in the list below. This course does not aim to teach the domain of e-commerce.
hybris Developer Training Part II—Commerce: This three-day hybris e-Commerce training is a hands-on training course designed to teach attendees the fundamentals of creating a high-quality, state-of-the-art e-commerce
application. The training uses instructor-guided technical trails to teach the developer step-by-step how to create a fully-featured e-commerce application using the hybris Accelerator. Over the course of the training, developers will learn how to implement an attractive and fully-functional merchandise web shop.
hybris System Administrator: This two-day class reviews hosting, running, and monitoring a hybris application and requires specific know-how on used system components and tools, as well as a general system overview. Browsing the whole technical hybris universe, participants learn to set up, install, test, and debug a hybris application. Project managers may attend this course, as it provides a broad range of information about how to deploy applications and data, backup/restore, monitor, and debug the application.
Other courses are also available. For training registration simply send a message to training@https://www.doczj.com/doc/7310939663.html, .
After classroom training we highly recommend our development trails, which are available on wiki. The trails are written as tutorials and will let you to write code, experiment, use, and modify functionality hybris platform provides. The development trails wiki also offers documentation describing the reference implementation (the Accelerator) from many aspects: Project Process Guide, Delivery Framework Guide, Functional Specification, Business Guide, Technical Design and End User Guide.
R O J E C T B E S T P R A C T I C E S
Certifi cation: hybris provides a certifi cation process to developers in order to help provide standards of hybris developer profi ciency. The hybris Core Developer Certifi cation is awarded to developers who have passed the hybris Core Developer Certifi cation Exam. This exam is designed to test a software developer’s ability to use and extend the hybris core platform. It is a best practice to certify your developers.
The hybris Commerce Developer Certifi cation is the second software developer exam in the hybris developer learning path. For developers who have already passed the hybris Core Developer Certifi cation Exam, the Commerce Developer exam further tests your understanding of the commerce concepts and APIs of the hybris platform.
4.5.2 SOFTWARE WORKSHOP
The software workshop is format that is intended for business users (non-technical audience) who will be working with the hybris platform. The workshop usually starts and facilitates discussion about required feature set, planned business processes and complexity of the project.
4.6 Multi-channel Accelerators
hybris Multichannel Accelerators enable hybris customers to jump-start their implementation of a feature-rich multichannel commerce solution. hybris Multichannel Accelerators are pre-built foundations that incorporate best-practice multichannel capabilities, including central product content and order management at its core, and state-of-the art marketing and merchandizing capabilities. The accelerators deliver the functionality and business tools organizations need to create an engaging customer experience, improve customer conversion and increase average order value across all channels. By offering sophisticated, integrated personalization, a large selection of promotions, powerful search and navigation capabilities, and rich product information including reviews, hybris Accelerators enables retailers and consumer brand manufacturers to boost multichannel sales faster than ever before.
With a fully-functional storefront, call center capabilities, and social network integration, the accelerators also offer support for additional channels like mobile, print and point-of-sale (POS). The accelerators also come with a wide array of ready-to-use backend integration points, how-to guides, sample data as well as best practice guidelines—all intended to simplify implementation and maintenance.
Furthermore, built using best-practice development coding and standards, the hybris Multichannel Accelerators deliver source code that organizations can easily customize without requiring heavy coding, accelerating the development process.
4.7 High Level Architecture
The technical team will identify what systems will be affected by the project and to what extent. Some components need to be implemented, some customized, and some reconfi gured. There could be dependencies on external systems during the project (e.g., reusing the testing framework) or beyond the project (e.g., integration with a CRM system). Ultimately, we need to choose and confi rm technologies used in the project.
There are many types of system and software components that can make up a hybris system architecture; there is probably not one “typical” hybris system architecture. The numbers of servers and components completely differs depending on implementation requirements. To give you an understanding of the kind of system and software
components you will typically work with on a project, starting with the hybris Multichannel Accelerator as a base, the following section describes how various types of component physically and logically fi t together. You can fi nd more details about each component in the counterpart sections of the hybris Multichannel Accelerator documentation on the hybris wiki.
R I S P R O J E C T B E S T P R A C T I C E S
It is common to use a web server, such as Apache, to store static assets such as images, CSS and JavaScript fi les. This is typically done to ensure the application server resources are not troubled with assets that can be served from the web server with greater performance.
Although it is possible to install all the software components in hybris on a single server, it is a best practice to setup a cluster of servers to separate the functions that are dedicated to serving real-time customer web requests and those that perform asynchronous processes or administration interfaces. This preference is driven by performance,
fault-tolerance, and networking security reasons.