Smart Manufacturing Today

-Scott Fuller, Xception This is the third in a series of six articles looking at how to successfully deliver your CRM project. Taking the time to look past the functional capability offered by a company will determine if you want a Partner or a Vendor. There are very good reasons to purchase your CRM solution from a Vendor, implement it asap and then just pay the Licence Fees for the term of the Agreement. Full Stop!! There are however more and far better reasons to look ahead to see how your full CRM ecosystem (Refer to Article 2 in this series) will support the evolution and growth of your business in the long term and how valuable a Partner can be. The behaviours of your Partner, vs a Vendor, are highlighted in Table 1 below. In short, a Vendor will give you exactly what you asked for and how you can leverage the generic capability and services. A Partner will take the time to understand your business, as well as technology, requirements and use them to drive out the right solutions. Project Factors Partner Vendor Shared Vision Drives the program Fits it to the tool Detailed Requirements Designs solutions Presents capability Functional Fit Customises for purpose Allows configuration Acceptance Testing Fully involved Facilitates how-to Training & Support Personalised / Periodic Modular / Static Resources – Time & $$$ Quoted / Evolves Fixed / Inflexible Table 1 – Partner vs Vendor So before starting your search for the right CRM, start by deciding the characteristics of your Partner, or Vendor. Will you deal directly with Vendor or via an implementation Partner? Either way, how do want to engage, what involvement do you expect, what services will you require to compliment your in-house resources? Is it more cost effective to pay an […]

If we want to create business solutions that better serve the environment, we need to shift our manufacturing mindset from take, make, waste – to reduce, return, reuse. This circular economy mindset, whereby products can be endlessly used through continuous business systems, is what gave birth to Computer Recycling. Computer Recycling is Aotearoa’s leading electronic waste recycler, recycling more that 4.8 million kilograms of waste since it was bought by Managing Director, Patrick Moynahan in 2018. Patrick took out a loan and used his personal savings to purchase and consolidate Computer Recycling into what it is today. The company’s goal is to eliminate electronic waste from the country’s landfills by actively engaging in sustainable recycling and reuse practices – a mission focused on driving Aotearoa’s circular economy. The average Kiwi produces 20kg of e-waste per year, which is one of the highest amounts per capita on Earth. That’s around 80,000 tonnes of e-waste per year – estimates suggest that a mere 2% of it is recycled. A lot of people don’t consider what happens to electronics, or waste in general, once it’s in the bin. It’s trickier for e-waste given it contains toxic plastics and metals which can harm our environment. That’s why it’s important e-waste is properly disposed of, and where applicable, recycled. For businesses, it’s one thing to manufacture and sell a product, but there needs to be equal consideration for what happens to that product at the end of its life. Businesses need to be responsible for a product’s entire lifecycle. It’s their responsibility to ensure products are disposed of / recycled properly, and they need to educate customers on appropriate disposal habits as part of that. At Computer Recycling, e-waste is both refurbished and recycled. Once the e-waste is gathered, it’s then brought back to Computer […]

This is the 2nd in a series of 6 articles looking at how to successfully deliver your CRM project. The full series contains: The purpose of the Architecture is to help teams develop the technical capability on time and on budget whilst ensuring it solves the problem for which it was designed. The Architecture will build on the very high-level view purported in the Charter and will contain: Concepts – A conceptual view of the stack and its moving parts for communication and context Option Analysis – Platforms, Languages and Tools in light of the functional and non-functional requirements. High Level Design – Features, phases and solution requirements at a Function level Detailed Design – More definition around areas of complexity Non-functional requirements including – Security, Performance, Maintainability, Scalability, Reliability, Usability and Risk The expected outcome is that both the business and technical requirements have been incorporated into a Solution. Specific technologies may be selected, short listed or used as examples as the Architecture develops over time. The Architecture is neither a Process Diagram nor the detailed User Requirements, which will be developed in the next phase of the project. 3 x Critical Success Factors These are CSFs for the Architecture, not the Project: Match the Solution to the Business Environment This is important in all major technology solutions but even more so with CRM deployments due to its role in supporting all customer facing interactions and integrating to all other teams. The Architecture must take a strategic view of the specific functional requirements and then the significance and importance of potential reliance’s on and impacts to other teams and their processes Desire vs Reality The simple approach of Why, What and How (Before When & Who) will assist in addressing this challenge: Why: The justification of the need for […]