Today we’re going to discuss the project scoping and approach. We begin with some as-is discovery where we're really focused on understanding how this organization has made use of Lawson, or potentially other third-party systems whose functionality will impact the move to CloudSuite. This action is always taken with an eye on practical scoping, so it's not a full-blown optimization assessment. We're really honing in on those details that are pertinent to the work effort and planning for CloudSuite implementation. The deliverable here is written in such a way that is easily digestible for your end users, stakeholders, as well as your executives, and it is something that could be reviewed with potential implementation partners. It should be very easy for them to objectively understand the best way to provide their recommended approach for CloudSuite implementation estimates.
What we're talking about here is a breakdown of business process requirements. For each of the business processes that are primarily in use in Lawson (which might also touch other systems), if a client is planning on moving them to CloudSuite, our consultants will evaluate the organizational requirements around that business process and decide how well they line up with the functionality of CloudSuite. This decision is based on a scale of standard functionality. We figure out if the application delivers the ability to execute that business process right out of the box with minimal configuration, and if the Infor provided test scripts accurately capture the execution of this business process at the organization. Perhaps there's some configuration review and other changes required, which would mean more time might need to be spent on this process during the design and build phase. In this case, you want to allocate effort to our implementation project that is specifically for this requirement because it diverges somewhat from the norm.
Finally, is this something that the application does not actually accommodate with out-of-the-box or built-in capability? If so, we know that we need some level of extension, customization, or integration with another system in order to effectively accomplish this implementation. It is absolutely critical to understand which of these processes are going to require that extra effort versus which ones will be more straightforward to produce. We never want to get into the design and build phase without having allocated time to deal with some of the more tricky or unique business processes. Examples of those processes would be GL restructure, HR restructure, jobs and positions, invoice approvals, and requisition approvals. Those are things that we often see as an opportunity to change the way an organization is doing things and help them break free of the limitations of Lawson so that they can fully make use of the advantages of CloudSuite.