pete.lagana

    November 2010 Previous month Next month

    As an interactive company, we are engaged in many digital projects that touch people in some way.  iPhone apps.  Websites.  Enterprise software.  Social Media apps.  These digital projects span different kinds of clients in different industries.  The type of project varies, the business requirements change, and we always need to put on our thinking caps to come up with a great user experience that hits the mark for our clients.  Clients are different.  Businesses are different.  And UI needs are different.  With all these differences though, there is one underlying truth that is always the same - out of the box UIs, at best, only partially hit the mark.

     

    The reason is simple – we see it every day.  Clients are placing increasing value in their digital offerings.  I can’t tell you how many times we’ve heard “Can you move this button?” or “Can you plug this screen into our other product?” or “Our customers need a seamless experience across all these apps.”  Clients always want to modify a packaged product to some degree.  It’s becoming more prevalent with each passing day - clients not only expect easy, simple, and fast for their users, but also expect a seamless UI across different software solutions, often from different software vendors.  This means combining SAP and non-SAP apps together to produce ONE seamless solution.

     

    With this in mind, we wanted to comment on the UI design approach with SAP BusinessByDesign.  In this article SAP is trying to make the UI better for some of its on-demand products.  And we think this is a noble attempt.  Everybody knows the oil and vinegar mix that somewhat describes SAP software and usability, so any attempt at remedying this is a step in the right direction.  But, in the end, the out of the box UIs will never be the end-all-be-all. Customers will always want to change it. 

     

    So, it’s really like putting a band-aid on a broken leg, or treating the symptom not the cause.  Its not about trying to hit the mark with out of the box UIs so much as it is allowing the UI to be as flexible as possible, expect modification, and make that process as inviting and easy as possible.  This is the new reality for user interfaces.  Facilitate customization, don’t resist it.

     

    Here’s an example.  One client we're working with wanted to produce a seamless user experience for its external customers that allowed them to create orders, process returns, create invoices, run reports, and administer users.  To the users, this was ONE process, or at least it was supposed to be.  But to the client, this was much more complex – many apps run by different software vendors (SAP, Microsoft, Ariba,IBM), all needing to be combined for their customers to offer end-to-end process-based solutions.  The old solution cobbled together many different user experiences from the disparate software solutions, to the point where help desk calls started getting so bad, that they needed to hire 10 new customer support advocates to handle the issues.  Customers often threatened to “jump ship” to a competitor whose UIs were “much easier to use”.  Similar processes like pagination, placement of form controls, UI patterns and actions – these were all different across each app, and worse, they were different across each SAP app.  But the customer needed to negotiate each UI to place an order, process a return, create an invoice, and run a report.  The number one help desk complaint - “Why is it that this all can’t work the same and look the same way – this is way too complicated.”

     

    The point is – it’s impossible for any out of the box product to satisfy all UI needs with a blanket approach.  Enterprises today often own many different kinds of software that they expose to their users, internal or external.  Different software with different UI layouts, design patterns, processes, aesthetics, and usability.  Each individual app may do a fairly good job of standing up a decent UI, but there will always be situations where that app needs to-be modified for some reason, and needs to be blended with other apps.   So, in our experience, it isn’t as much about producing UIs out of the box that try to meet all user experience needs, but rather create a UI that is extremely flexible, and lends itself toward change - because change is the norm in the digital UI world.  Since customers always want more, out of the box solutions will almost certainly fall short. 

     

    We would like to think of SAP software as clay – the soft maleable kind, not the hard, dry kind.  Soft clay would be UIs that anticipate and facilitate customization.  Hard clay would be out of the box UIs, and the blanket expectation that it will work for all users.  Some will say – "well you can still use a chisel to make the hard clay be what you want it to be."  This is true, but you lose pieces.  Not to mention, you'll have difficulty correcting mistakes.  We don’t want to lose pieces of SAP because of out of the box constraints. 

     

    From a design perspective, out of the box UIs should have the ability to heal, to be soft clay.  Make customization and modification simple and inviting.  Expect it.  Embrace it.  Foster it.  In the end everyone wins, users will get what they need, and SAP will look very good in the process.

    After returning from Tech Ed, SAP's new strategy is firmly cemented in my mind -  on device, on demand, on premise.  Having done lot's of UI projects for clients where the user experience has been extremely important to success, on device has special meaning to me.  It means designing a user interface that hits the mark with users, is appealing and flexible, and is certainly anything other than out of the box.  That's one of the things I've learned over the years in terms of designing great digital User Interfaces for clients - out of the box UIs are becoming more and more unacceptable. 

     

    And its no different for SAP. 

     

    Sure, everybody knows the power of the SAP backend, but can the SAP front end, the “true” user experience, match that power?  That's what today's digital users have come to expect - great UIs.  At Excellis, these are the kinds of things flowing through our mind daily, as we look for the best ways to make SAP simple and appealing across many different devices and many different platforms.  Its what we do all day, everyday - make SAP look great - and there's lots of products to pick from - to name a few: Web Dynpro ABAP and Java, NW Portal, CRM Web Shop / ISA, Bobj / Webi, and now Sybase as well.  The thing is, all of these UIs are being rolled out to users to access the backend of SAP in some way.  We always ask, what if that accessing of backend SAP was easier - so users can have it their way, in terms of utilizing SAP data to do their work? 

     

    And then I ran across some information on Project Gateway, and that's when the juices started flowing.

     

    Here’s what we learned - "Project Gateway enables UI-centric consumption of SAP Business Suite data by popular devices or platforms in an easy and standards-based fashion".  

     

    It's not that connecting to SAP from these devices and platforms was a foreign concept before - it's just that now it's easier.  “On device” is really is a microcosm of reality.  There are so many devices and platforms today, which equates to all of the UIs being different.  Embracing the fact that customizing UIs are what users want, and making it easy to access SAP on top of that, makes touching 1 billion people with SAP a whole lot easier.  Project Gateway makes accessing SAP easier than pure web service consumption or with JCA, which was the way to do it in the past.

     

    While the direct benefit of project gateway is open APIs to SAP (with standards), there is more of an indirect underlying message with all of this - UX design.   I think now UIs can be designed for SAP projects more from a traditional UX project perspective - around the users and how they work and what they need.  Project gateway places prominence on designing truly great UI's on any device or platform. Because now the focus can be around improving the users experience on their platform of choice, and not on writing tons of custom code to access SAP or change it's out of the box UIs.

     

    With Project Gateway, we get a chance to see how SAP is recognizing this rise in the prominence of UIs, and how important it is to get the user experience right.  I believe Gateway will help SAP keep pace with users' growing UI expectations in terms of creating UI flexibility and allowing clients to have their own UIs that consume SAP.  It’s a win-win situation.  SAP back ends will still be utilized, and users will still get the UIs that they want - exactly as they want it, without having to settle for constraints in flexibility or out of the box shortcomings.  This ultimately makes the role and craft of UX design much more prominent on SAP projects moving forward.  Now, true user centered design can prominently take place on sap based projects where things like wireframes and mockups are no longer dirty words and don't produce eye rolls.  Instead the focus shifts from what can’t we do to what can we do.  Users don’t care about why something “can’t” be done, only that it “can” be done.  They want easy and they want fast.

     

    So with Project Gateway - it looks like SAP has finally realized - that the power of the front end is just as powerful as the back end.   Times have changed.  Users want more.  And now with a focus on the UI, they’re in line to get it.

    Being an interactive shop, we always are looking to produce the best user experience possible for our clients.  And because we do a lot of SAP projects, it's inevitable that those customers also run some version of the SAP Netweaver Portal. 

    What has been increasingly evident over the last year, is that most of those same clients ALSO run some manner of Microsoft SharePoint.  Some companies will use SharePoint extensively, while others barely use it even for document management.  So, this is typically the backdrop of conversations that start out something like this: " We have the SAP NetWeaver Portal - but we also have Microsoft SharePoint Portal.  Which one should we use, should they be standalone, or merged?". 

    That question seems to always come up for clients who have both SAP and SharePoint.  And it's not slowing down.

     The answer to that question really can get quite complicated, and can go in many different directions.  For now, though, I thought it would be helpful to list the things that we talk about with clients when consulting on SAP / SharePoint integration:

     

    1.  User Experience. From a UX perspective, the SAP up a few ways to deliver UIs through SAP Netweaver Portal - all the familiar names such as BSPs, WebDynpros, JSPDynPages, etc.  These are controlled through a massive array of style sheets, and can be accessed directly from the server or via the Theme Editor.  With SharePoint, styles are controlled through SharePoint Designer.  So if you are familiar with your typical WYSIWYGs, then you will be in good shape.  Be sure to start out with a clean masterpage, though, or it could get messy.  

     

    Advantage?  SharePoint.  Because SPX (SharePoint Designer) allows you to adjust the master page layout which controls all of their UIs (ASPX pages, InfoPath forms), you can start with minimal css layouts, and keep it clean.  For the Netweaver Portal, there is a lot of style sheets there to sort through, and going through the theme editor is much more limiting than SPX.  You can produce great user experiences in both NW Portal, and SharePoint, but experience and know-how are generally the secret sauce to make it look great. 

    2.  Connection and Communication.  This really boils down to which platform is easier to integrate to, in other words - which is more open.  Connection and communication could come in the form of pre-built connectors, using applications like Duet, or  writing custom code.  Here we are really talking about APIs, Web  Services, and/or SOA.  Having done a bunch of projects for both NW Portal and SP Portal, its usually custom code that best enables integration.  Also worth mentioning here is connection and communication via the Federated Portal Network.  FPN provides a way for SP Portal and NW Portal to recognize and trust each other.  Throug set up and system configuration, FPN does present an alternative to APIs, Web Services and SOA.  We've set up a few FPNs at clients with this hybrid scenario, and it has worked well, especially in situations where iViews need to be surfaced in SP Portal, or WebParts need to be surfaced in NW Portal.  FPN provides soem interoperability in these cases.  

    Advantage?  Even.  Both are about the same to integrate to.  Just different code, different syntax, different configurations.  

    3.  Content and Collaboration.  SAP does a good joob with the KMC product, and we've built some great solutions utilizing the KM API's (http://www.pfizerpro.com/products).  Can be pretty light and fast.  But document management and collaboration within the sharepoint platform is probably more robust.  The ability to administrate freely, the lightness of the layout, and the ability to scale horizontally make it easy to work with.

    Advantage? SharePoint  Given the extensibiity of the collaboration tools, and the horizontal scalability.

    4.  Single Sign On.  SAP Logon tickets rule.  Let me just say that right now.  I can't tell you how many times we've integrated SSO to an SAP portal, and most of the solution has come from manipulating the logon tickets.  With SharePoint, there are some close equivalents, but you'll generally need Kerberos to integrate fully.  Here again, FPN, once set up correctly, can allow simple sign-sign between systems, once trust has been established.

    Advantage? SAP.  Logon tickets push the advantage SAP's way.

    5.  Unified Search.  Search is an important factor with both platforms.  SAP Portal touts the TrEX search engine, and integrates to SAP Enterprise Search.  MS SharePoint has its own unified search, that also allows drill down by meta and quick sub searches.

    Advantage? SharePoint.  Reason - open APIs for the indexes and repositories, and easy manipulation of the search results layout.

    Final Thoughts for now - both platforms have their advantages and disadvantages.  SharePoint tends to be the UI Portal that sits on top for most clients we've seen, and SAP content is pumped in as iViews.  However, we've implemented it the other way around too, and that's been pretty successful as well.  I think the ramp-up of Gateway will help influence this topic significantly over the next year, and I'll be writing about that in another post.  But for now, SAP Netweaver and Microsoft SharePoint are two major factors in the enterprise ux market.  I tend to think, based on experience, that they can most certainly co-exist quite nicely.  The business case is certainly there for that.