I have some questions related to the integration between Hybris and SAP, and I would appreciate if someone could throw some light on these doubts I have.
Ref: https://help.hybris.com/6.2.0/hcd/8c6b1537866910148811df9d8ce1e582.html
The above link explains how SAP can be integrated with Hybris so that the Order Management can be handled by SAP. It also suggests that SAP can be leveraged for pricing and tax calculation which means that Hybris can be bypassed.
Similarly there can be integrations with external PIM (Product Information Management), CRM and other business processes.
Hybris, as I understand manages the product, orders, taxes, etc... If in a real life scenario, all this information and business processes are managed from outside Hybris, then what is the purpose of having Hybris? Is it only a front-end app then?
Other references that made me ask this question:
https://help.hybris.com/6.0.0/hcd/99fd9ee7e7654886a95744c34da1dfb6.html
https://help.hybris.com/6.0.0/hcd/8c7087fe86691014b45ada177449dcdb.html
Hybris is a platform with a set of modules that provide different features for your business.
In real life you will use some of hybris' modules and also external tools such as SAP ERP for example.
Hybris offer integration with a lot a partners in order to meet customer needs. When a company wants to build an e-commerce platform using hybris it might also want to reuse existing elements of the company (CRM, PIM, etc...). Sometimes, the modules from hybris don't fit customers needs and they prefer to use other tools for a specific area (could be cheaper to implement). That's why it's great to have the possibility to integrate hybris with other softwares.
You can also start a project without using any module of hybris but the accelerator. Then you'll have the opportunity to migrate your existing module into hybris to build a powerfull multi-channel solution.
It's up to you to use hybris ootb modules and/or external tools, it depends what you really need!
Related
I am pretty new to Hybris. I am a bit curious about the activities that are taken care of by the production support team in Hybris. please share the information about what are the activities generally a production support person take care.
Maybe this can give you some idea:
Study guide for SAP Certified Support Specialist - SAP Commerce 1811: https://cxwiki.sap.com/display/education/Study+guide+for+SAP+Certified+Support+Specialist+-+SAP+Commerce+1811
I think the scope can be quite big, and it will depend on your contract / agreement. It could cover things like:
Handling day-to-day operations (e.g. backups)
Managing releases or patches
Managing users (e.g. Creating/Updating accounts manually)
Operating Backoffice (e.g. Reloading the widgets, etc) or PCM
Monitoring the system (e.g. Using DynaTrace)
Fixing performance issues
Fixing synchronization issues
Setting up the infrastructure (e.g. clustering, caching, logging, etc)
Being familiar with integration with other services (e.g. Data Hub)
Knowing how to indetify and fix issues / problems in general
etc
I am working on customization of some order flows in Hybris and want to know what is exact difference between order management and fulfillment modules in Hybris. Also, when should we use which one of the above? Thanks.
Order management is part of a module you have to pay for (OMS). It contains a lot of workflows and frontends to handle orders after they have been created.
The fulfillment extension is part of the accelerator module and just adds the most basic processes to handle an order. When you need more than that, you will have to implement yourself.
I would suggest you make yourself familiar with the OMS module. If that fits your needs and your company wants to pay for it, you can use it.
When you say Order management it covers order fulfillment already.
There are two things
Standard SAP Commerce order management
Order Management Services (OMS) - this comes with a different license
For SAP Commerce order management, there are extensions like saporderexchange, ysaporderfulfillment etc
For OMS, there are extensions like ysapomsfulfillment, saporderexchangeoms etc
Refer this for more details
While I'm learning Microsoft Dynamics CRM 2015, I find out that there is a good built-in software infrastructure available to generate new modules.
Although the features available in the UI are so limited. But working with its SDK, seems it can be used as a tool to create software.
Question1: Is it appropriate to use Dynamics CRM to develop some software unrelated to CRM, for example, Production Planning, Logistics, Warehousing, Accounting, Payroll Systems,....
Question2: How does it compare to other solutions like using DevExpress XAF, Light Switch or solutions like these?
Yes, absolutely, especially with the latest updates to CRM 2015 Online (available On-Prem soon) that allow you to batch updates in database transactions. I have created Student Information solutions, Oil Well management solutions, Real-Estate solutions, Loan management solutions, Donation management systems and several other smaller solutions using the Dynamics CRM framework.
The biggest difference is in how you design solutions. Like any framework, almost anything is possible in CRM but you must design your solutions around the framework features. If you are using a lower-level framework like DevExpress or LightSwitch or even just .NET code, you will have much more power over your user interfaces and code. But with that power comes much more responsibility in maintenance and interface design. Once you get a handle on CRM, you can create almost anything quickly without worrying about the "plumbing." You just have to learn all the different framework features and the associated limitations.
Question 1:
It is definitely possible to use CRM for completely unrelated things. At my current job as a Business Applications Consultant, we use CRM as a starting point and utilize:
Plugins
Web Resources (mostly JS)
Workflows
These different things help us customize how the system works for each individual client. But more specifically your question, yes, we have developed systems for warehouse management.
Question 2: I cannot speak to the differences between these different things as I am only familiar with CRM.
That's only one opinion from a CRM Dev. Hope you get more and more!
My company is in need of a task management system to handle scenarios as simple as "Purchase a computer for X" to "Relocate a person to another country". The simple scenarios are a single tasks handled by a single person, whereas bigger tasks can be broken down into multiple sub tasks delegated to multiple people during the workflow. Additionally the clients and vendors need their own views into the process.
We are evaluating different solutions from a custom application built on Workflow Foundation to SharePoint to BPM products like Metastorm and BPM.Net.
Here's my current understanding of these solutions:
Workflow Foundation - Low level workflow designer and/or library with no host environment. It seems we would have to reinvent some wheels if we went this route such as fault tolerance and document management. Some of the answers on stack also cause concerns such as the lack of versioning and a complete overhaul for VS10/.NET 4.0
SharePoint - Built for document management and collaboration but trying to create advanced workflows and tasking on top of that seems like a hack. Plus all workflows have to be tied to either documents or lists. I cant envision how a list (or list of lists) can address this issue.
BPM products - Mature workflow engine at a seemingly high price. BPM.Net is the only solution for which I could find some level of technical detail but im still not sure how different developing against this product would be from developing against Workflow Foundation.
Are there any workflow engines dedicated to solving all the workflow pains that can be easily deployed with their own hosting environment and initiated through a webservice?
Are there any other options I am missing?
Thanks in advance.
****Edit**
To answer the questions below the workflow needs are pretty light. Basic routing of tasks to approvers and subcontractors.
Whats driving us too look deeper than PM software is the nature of the business not the need for advanced workflow. We are basically in the business of procuring goods and services through subcontractors for our clients which can also include full employee relocation. The interface of the package should reflect this by being customer branded as well as intuitive for this line of business.
Basically if im moving my family to the other side of the world Im not sure i'd want to interface with Jira or Sharepoint or any other PM software to facilitate this.
If you are on Microsoft stack I would definitely recommend SharePoint for this scenario. As it seems to be very simple you can go with Windows SharePoint Services edition because it is free and it has everything you need.
You are right when you say that ShartePoint workflow are bit limited. IMHO the best way to overcome that limitation is to purchase Nintex workflow to create your workflows. It is cost effective solution that can help you design workflows you need.
You can find workflow samples inside the product (as workflow templates) and on the web site.
Nothing you mentioned has much to do with workflow. You're just doing project management. If that's the case, a simple bug tracker (like FogBugz! ;) would work - but if you're going to show it externally, it may not be the most professional presentation.
The closest off the shelf solution I can think of would be Project Server - though, depending on the number of projects and project managers, the desktop Project with a sync to a webserver for client views may be enough.
If that's overkill - because your projects don't require a lot of resource scheduling, Gantt charts, or other PM artifacts - you can take something like Trac and replace "bug" with "task". ;) (Seriously though, that'd probably get you 90% of the way there.....)
Have you looked at RT? I believe it can handle all your requirements, including that it's designed to let customers interact with the system by email, rather than having to log into the website. If you've emailed IT support desks then you've probably interacted with it without knowing... You can also completely customise the web interface and allow customer access.
Can't vouch for the quality as I haven't used it, but I did watch an online-demo video of Intalio, which has BPM and workflow capabilities.
We use Basecamp to control this sort of "task management" stuff. I'm not sure if it fits your needs totally, as it's a little light on the document management side, but it has a web service (REST) API, customer / vendor facing components, and basic interaction / chat capabilities.
The best part about it is that the API is simple enough where you can offload a lot of the "management" for it to admin support personnel, like assistants and interns, by providing custom scripts. If you've got people who aren't programmers using it you'll probably have better luck with it than even something like Trac or FogBugz.
I have/am going through a similar process. We wanted a lightweight workflow for internal use by our sales team. Most of the third party apps we looked at ,K2 and Skelta BPM.Net in particular, looked way over the top for what we needed. I'm now 2 months into working with Windows Workflow Foundation 3.0 and I have to say it isn't the most pleasant coding experience I've had.
If your workflows will truely be simple then it is pretty easy to build a workflow and hook it up to some web pages for the UI. But if you need to be able to change it on the fly, or do versioning (ie the user says we want another step added, then its a whole lot of hacking to get it to work - and it only works if you limit your workflow to being really simple), then you are in for a fair bit of work. And forget about it if you use an Oracle database.
The next version of windows workflow will have it's own runtime environment, code name dublin, with will provide a WCF interface into the workflows.
If your timeframe allows you could use that.
For information on Dublin and the next version of WF see:
http://www.microsoft.com/net/dublin.aspx
My vote is for FogBugz. Unless I am missing something in your requirements, why would you want to reinvent the wheel by using a code based workflow solution where you have to code up the flows yourself when you can use a perfectly good project dependency solution like FB or even MS Project Server - which lets you create nice dependencies for resources and people.
Check FileNet
FileNet is expensive but makes a good job with content and process management, but I guess is not what you are looking for.
We use Captaris Workflow, it is pretty good but it may be expensive for your needs.
At our company we are currenty trying to define the basic things our software architects have to know about SharePoint for them to architect and/or lead a SharePoint implementation project. Many architects in our company have a .NET developer background and know a lot about .NET development and the various framework components and tooling. However, they currently lack SharePoint knowledge. In fact they don't even want to know the nitty gritty details. They want to know just enough about it to make the right architectural decisions and apply proven patterns. If more specific knowledge is required they'll ask a SharePoint expert.
So What would is the basic set of SharePoint knowledge / skills that an architect would need to have?
Skills such as list, documents, workflow, permissions... are a bit too basic and are requirement for a SharePoint DEVELOPER.
I'd argue that perhaps site (and site structure) is an area that would fall under the architect's plate.
There are more areas that a SharePoint architect can help with:
Capacity planning - running multiple servers in a farm. Scalability and other magic words.
Knowing the capabilities and business scenarios of using SharePoint - this is a very common one.
The manager asks: what can SharePoint do for me?
The developer asks: well, what do you want it to do.
The manager then asks: well, I don't know what it can do for me so how do I know what do I want it to do?
Closely related to SharePoint capabilities are the various licensing costs related to each component.
As well as familiarity with development and customization costs. Take the same project time that would have taken in ASP.NET, then multiply it by a large coefficient, and then add an additional constant.
And closely related to what-can-it-do, and how-much-does-it-cost, is the all important question of Return-Of-Investment. All hail supreme ROI!
SharePoint deployment can be a massive issue and a lot of pain.
SharePoint upgrade from v2 (MOSS 2003) to v3 (MOSS 2007). We should be seeing a new version of SharePoint in 2010(?). Well soon after the next version of Office goes out the door. So past upgrade experiences may be useful.
Knowledge of 3rd party webparts. I believe a SharePoint architect should be able to give you at least 5 webparts that they've tried from CodePlex and tell you what they think about them. These are free and easy to grab and play at your own leisure.
Some knowledge of commercial webparts. Because they are still cheaper than writing your own.
Have at least 5 SharePoint blogs that they follow religiously (know the community). If not having their own SharePoint blog (give back to the community).
If they are on StackOverflow they must try to answer SharePoint questions (such as this one).
Attend local SharePoint usergroups. I think communities are a huge deal. Especially what you'd learn from talking with people directly and learning what they are doing with their SharePoint installation. You may just surprise yourself.
Experiences with SharePoint Integration - this comes in two equally important flavours - both from SharePoint accessing existing systems (business catalogs, webparts, etc), as well as other systems accessing SharePoint content via webservice or API.
In addition, SharePoint works with (or works well) with Office, OCS, reporting services, performance point, project server.
SharePoint hosting arrangements - Microsoft SharePoint online services can be a popular and cheaper option to start using SharePoint. It can be hosted inhouse, or with a 3rd party company. Knowing the options is always useful.
Must have read SharePoint code using reflector (and preferably still having hair).
I think it takes at least a couple of years to be a SharePoint architect (your mileage may differ). Your .NET architects need to want-to-be a SharePoint architect, otherwise I agree with other's summaries before me - find someone who already is a SharePoint architect.
An architect should have quite a good understanding of our a product works, from a functional and technical viewpoint.
So in my opinion, an architect should:
Have been involved in at least 2 Sharepoint deployments, from design to roll-out.
Have knowledge of our the major sharepoint components can be used using the API.
i.e. Sites, Lists, Documents & Workflow components.
As none of your architects have this knowledge, I would pair them with a Sharepoint expert in an existing Sharepoint project, so they get the knowledge they need.
Ideally SharePoint Architect Skills fall into the below mentioned categories
Infrastructure Level/Operational
Capacity Planning
Physical Architecture (Farm Setup, Network, OS, Licensing)
Application level (Functional and Non-Functional)\
Requirement and Feasibility Analysis (Custom Vs OOTB Development/Implementation)
Techno-functional Mapping of requirements
Information Architecture
Logical Architecture
Conceptual Architecture
Detailed Design
Database design (not in terms of traditional Database design), this is with respect to Number of content Databases for Site collections/web apps.
Deployment
Best way to go for deployment, first time and incremental
Some other activities that an architect will collaboratively work is the Project Manager in Planning, Estimation, Execution/Implementation, Risk Management (assessment, mitigation).
Apart from his daily tasks of working with technical teams, testers, User Interface professionals, Vendors, Clients (Business and IT teams).
Interacting with Enterprise Architect groups if any.
In my not so humble opinion I think the entire "Sharepoint Architect"/"Expert" thing is over-played.
Sharepoint is a tool to centralize an organizations digital resources for centralized collaboration or working together in a centralized way.
The best explanation of What Microsoft Sharepoint is and does
from the WROX book "Beginning Sharepoint 2010 - Building Business Solutions"
"Because computers play such an integral part in any business, not surprisingly, more and more
of the information that is created, consumed, and shared in an organization is digital. The more
business that you conduct and the more successful your business becomes, the more information you
have to manage. Usually, you have some form of document for just about every process and transaction
that plays out during the day-to-day operations of your company. From proposals to legal
documents, from sales receipts to human resources policies, the amount of information required for
a company to function is staggering.
To manage your information overload, SharePoint offers tools with which you can build business
applications to better store, share, and manage digital information. With it, you can create lists,
libraries, and websites for your various company teams to help run your business processes more
efficiently. By locating your organization’s important business data in a single location, it becomes
much easier and intuitive for users to find the right information when they need it rather than
searching through disparate locations such as email, computer hard drives, or file shares.
WHAT IS SHAREPOINT 2010?
SharePoint 2010 is an extensible and scalable web-based platform consisting of tools and technologies
that support the collaboration and sharing of information within teams, throughout the enterprise and
on the web. The total package is a platform on which you can build business applications to help you
better store, share, and manage digital information within your organization. Because you can build
with or without code, the package empowers the average business user to create, deploy, and manage
team websites, without depending on skilled resources, such as systems administrators or developers.
Using lists, libraries, and web parts, you can transform team websites into business applications built specifically around making your organization’s business processes more efficient."
Creating a schema for an organizations Sharepoint deployment is not rocket science. 1. Determine the structure of the organization 2. Determine what Sharepoint can do as far as centralizing the organizations digital resources. 3. Create a Sharepoint construction plan. 4. Build it, test it, refine it. 5. Maintain it, test it, refine it, add onto it. There! Not so tough.
Sharepoint can be a nasty beast to work with if you don't know the ins and outs of it (they should be experts with it to architect it). At a minimum, they should know how lists, sites, and permissions work. Ideally they should also know how all the web parts fit together on pages and how they are supposed to interact. Really if the architects don't want to learn about sharepoint, they are going to create a .net web application and force it to run on sharepoint. It won't really follow the paradigm of how a sharepoint app is supposed to work.
I would look at a company called Mind Sharp for guidence as to what they should learn.
My advice is look for a doer that doesn't just reads PowerPoint to much in the Sharepoint world is just based on what other people have said.
We have been having issues with crawling 500000 items in a Sharepoint farm and everyone gives another story how to get better speed... Normally people refer to not more than 2000 items in a folder, but that does not change the crawl speed....
So a good architecture is someone who is able to do POC proof of concepts himself of his design and not just refers to some vague stories.....
I have seen to many Sharepoint Architects that hasn't had experience from real life....