In order to design an Application, it is essential to start by considering the business need. What is the business problem that is to be solved? Can it be separated into easier to manage chunks and considered separately? Can the problem be described as a repeatable process with a defined set of steps involved? Most things can if you think them through carefully, particularly if you isolate ‘exceptions’ as separate processes.
Almost any business need involves thinking through some key topics. Not all of them will apply to every problem, but you should think through all of them and check if they do.
What types of data are involved in the process? Is it existing data (e.g. standard stuff like records of People and Organisations) or a new ‘type’ of data (PYXI Record Types)?
What individual pieces of information need to be stored on a record? Each piece of information (such as a Name, Serial Number, type, colour, date etc) is a ‘field’ – if you were listing such data in a spreadsheet, then each column of organised data is probably a (PYXI Field). For each of these fields, is the data entered (manually or loaded from somewhere else), derived by being calculated, created as part of a process step (PYXI Step)? Can it be changed directly by a user or only under careful control by a defined process step?
Where does the data come from? How will it get into the application – by users typing it in, by loading it from files (once only or regularly) or by building an interface with an existing system?
How will users find the records they need? What pieces of information might be used to find an individual record, or to view a subset of records for a particular reason (PYXI Filters)?
How should users interact with the process? How do they know how and when to interact? When someone contacts the organisation, in which case the interaction steps need to be available on the contact’s record? By looking at a particular report or page on a regular basis? By getting alerted to records that are in a particular ‘state’ or condition?
Which users should interact with the process and its data? Is it all users, or a defined subset? Even if it is all users now, it is good practice to assume that this won’t always be the case, so consider setting up everything in the process to be accessed by a particular Group, even if an account starts with all its users belonging to that group. Consider whether there is a difference between users who can see information and those that can change it, and which information can be changed by straight-forward editing and which can only be changed in defined ways as part of a managed step.
How much of the process needs to be automated? This can take many forms.
Background logic can be applied to any record each time it is added or edited (PYXI Automations), or can be applied overnight to deal with changes that apply over time, such as triggering recurring processes or those that need to take place after a specified length of time (PYXI overnight Automations).
For more sophisticated automation, PYXI has a comprehensive Application Programming Interface (API) which enables you to develop communication between PYXI and any other web-based system. The API gives full power to read and write data in PYXI, to trigger events and process steps, and to load and extract data as needed.
How will data be turned into useful information?
How do users need to see information? Long gone are the days when reporting out of computer systems meant just churning out a long list of data on paper, although this can still be done if needed, of course.
More important is to consider what the user needs to see and why. Often, users need to be informed about the exceptions rather than everything that is working ‘correctly’.
Who needs to see this information, and when do they need to see it?
Does a user need a report to be told what to do next (possibly indicating exactly what records need to be acted on), or is their role more about analysing many records in order to understand how the business is behaving?
Data provenance, security and audit has become more prevalent as an every-day business issue to be considered, particularly given new data privacy legislation in jurisdictions around the world.
PYXI deals with Data Audit for you – every creation or edit of a record is recorded, together with who did it, when, whether it was triggered by an automated Automation, and if the data came from a data load or an interface from another system.
From a business perspective, you need to consider data security as part of your user security consideration – who can see it, who can change it, and whether changes to it need to be controlled. In addition, if users can extract the data, for what purpose are they extracting it and does this need to be recorded? PYXI helps with this as well. If you flag an item of data (a Field) as holding Personal Information, then users are warned when such data is about to be included in a data extract, and are required to record the reason why they need that information. This reason is then available as part of your Data Audit processes – vital if being investigated under data protection legislation.
For even more comprehensive data security and compliance, you might wish to consider including some of the pre-existing Blueprints in your application. There are Blueprints covering GDPR (General Data Protection Regulations) compliance recording as well as more generic Data Security compliance which helps with recording details of your systems, data flows and IT security.