Purebiz Blog

Autumn Leaves

The Purebiz Blog

This blog is all about Purebiz news and commentary. It may be directly related to Purebiz, writing software or the business world we all have to operate in. Anyway I hope to be adding to this blog frequently and I hope that you find it interesting.

Thanks for visiting. Graeme.

When I am asked to visit a business for the first time it is usually because they have a problem. The owner or a middle manager perhaps has the job of finding a piece of software that will solve this problem.

They look at a piece of software or ask for a demonstration and in their mind imagine using the software in their own context. This is not an easy thing to do. Often they will get a trial version and work through the problem with that. This takes a long time and is difficult to do when you are not familiar with the software. Often the task is not completed and the pain persists.

This why I take a different approach. I don't necessarily show the prospect Purebiz during the first interview. Rather I ask them to descibe the problem they face. How do they handle it now? What is unsatisfactory with their current solution? I ask about the context of the problem. What processes suround this issue? This way I can figure out how suitable Purebiz is for the job as it is now, what changes if any are required, if Purebiz can solve this problem at all.

Then on a second visit I will be able to show them Purebiz and how they will use it in their context to solve their problem. Purebiz cn be changed easily to handle almost any situation and if changes to Purebiz are useful to others I will not charge to make the changes. I can achieve almost 100% fit for your business. It doesn't happen over night but slowly and surely bottlenecks are removed and the customer's business efficiency goes up.

The first interview is all about defining the customer's requirements so that they can be met and a cost effective solution can be implemented.

Thanks for reading.

Yesterday I was preparing a script for a Purebiz video tutorial on user password management. Writing these scripts makes you think very carefully, has Purebiz got the security it needs? I am confident that it does but I was rummaging around in my email and found an email from Xero sent the day before, all about their security problems.

It said in short that some of their users had had their passwords stolen, and that they were going to force all their users to change their passwords.

Because anyone with an internet connection and a browser can potentially access your entire accounting system it is no wonder they were concerned. This is what a lot of people like about web based applications, they are so easy to get at. But it is their down fall as well.

Some Accountants and bookkeepers love this easy access for their own convenience but have made some silly mistakes with their customers passwords.

Xero blame an increase in phishing scams. If you want to know more about what a phishing scam is I refer you to the following web sites:

Austrailian Competition and Consumer Commission

Identity theft is on the rise, in the 2012 financial year the Australian tax office confirmed to the Herald Sun that more than 23,300 Australian Tax File Numbers were compromised. Can you think of a better place to bag a swag of Tax File Numbers than accounting programs? And please don't tell me your Accounting System password is the same as your email password. That is asking for a world of pain.

Purebiz does not suffer the short coming of being universally accessible because key areas of the program can not be accessed via a web browser. You need the Purebiz client to access all of the security features. You must buy tokens to access Purebiz, even with a password, and we don't sell tokens to people we don't trust. Every Admin user is set up by me so I know their passwords are good, at least initially. Please use passwords that are at least nine characters long and include both upper and lower case letters, numbers and non alphanumeric characters. Don't use words that are in the dictionary. Passwords are encrypted in the database and only the Purebiz client software can read them. We use SSH Tunneling for all internet communication. SSH Tunneling creates a secure connection between your computer and our remote server. We are very serious about security.

Well I am making good progress with the video tutorials so check them out at www.purebiz.biz. Thanks for reading.

Hi, I am going to talk to you today about Data Normalisation, something that happens behind the scenes all the time while a database system is being designed and that you may not notice but the effect is profound. And on the surface it looks pretty simple but as I will show it can be complicated.

In short Data Normalisation is the arrangement of data in a database to reduce redundancy. Let me give you an example. Let's suppose that you are writing a database and need to store information about a person and their phones. Let's also suppose that you want this information so that you and others that have access to your database can contact them (you may be writing the database to handle phone warranties which would mean that it would look quite different) . This is a pretty standard requirement that you will often come across.

The first thing most people do (especially those who solve every problem with a spreadsheet) will set up a table or grid that has column headings like "First Name", "Surname", "MobilePhoneNumber", "OfficePhoneNumber", "HomePhoneNumber". When you begin adding data one of the first things that you notice is that not everyone has each of these phone numbers or you don't have the data. This leaves "holes" or empty cells in the table, cells without data. So what you say. Well in this example it may not be all that important but if we were recording millions of names and phone numbers these gaps could add up to a lot of wasted space and that cost money and will slow the system down.

Next thing that will happen is that you will come across someone who has something different, 2 mobile phones for example. There can be lots of reasons for a person having two mobile phones. We have to foresee every possibility when we plan, we have to cope with everything that may come along. So what is the answer? Do we add another column to the table? That would add a lot of wasted space to the table (few people have two mobiles). And what if you wanted to add a piece of information about each phone, its type for example, or which number the person prefers us to use. Information may be important for other reasons, Purebiz will not attempt to send SMS messages to phones that are not mobile phones and we keep track of the best number to be used to get hold of someone. In our example we would have to add 6 and possibly 8 more fields to the table. Our very simple table could have up to 14 columns in it already and let's face it we have only just started.

The answer is Normalisation. Split the data into smaller tables that contain information about one thing or object. A person and a phone are different things so put them into different tables. And give each record a unique ID. This acts as a handle for the information. Once you have an ID or a handle you can link records in one table to records in the other. Take the phone information out of our example table and add the ID and you are left with "ID", "First Name", "Surname". Put the Phone information into its own table and you get "ID", "PersonID", "PhoneType", "PhoneNumber", "Perfered".

So now a person can have as many different phones as you want. Each Phone record is linked to a Person record by the ID in PersonID field of the Phone table. Each Phone record has its own ID because this is the only way we can unambiguously identify that record in the database and programs like Purebiz use these ID to get the information that you ask for. You may want to add more information to the Person table, it depends on your interest, shoe size for example may be information that you want to collect and it would be pretty safe just to add a field. But what about email addresses? I know many people who have many email addresses so adding new fields to the Person table would not be the answer. You need another table like the Phones table, one that links to the Person table.

So you think you are out of the woods when it comes to people and phone numbers? No so. Because some phone numbers are not assigned to people. They may be assigned to businesses generally or positions within the business and the person in that position may change every day, a Loading Dock supervisor for example. The whole business of Data Normalisation can be very tricky and when I am designing I have a rule: Never do the impossible, ie in this case, never create a situation where a person can only ever have 3 phone numbers. It is just not real.

I was asked recently to help a business that had a problem with a spreadsheet. This manufacturer made a product that was very complex and the customer needed a lot of help deciding on the specifications of their purchase. So 10 years ago a very clever employee wrote a spreadsheet that would take the customer's requirements and produce a manufacturing specification for the product. All was well in the beginning; they created a new spreadsheet for each job and produced their products, until the employee who wrote the spreadsheet left the business. When changes were needed they tried to "patch" the spreadsheet but failed. The only person who knew how the spreadsheet worked was unavailable. Time went on and the spreadsheet became more and more useless. New materials could not be added, the pricing could not be updated etc. When I was referred to them it had been two years since the author had left the business and the issue had become very urgent.

The first thing I noticed was the spreadsheet was very complex. Unnecessarily so in my opinion. And because it was so complex it had errors that had not been corrected. There were a large number of these files and they were stored in many different places. It was a real mess.

The problem with spreadsheets is that they are often written by people who know just enough. Just enough to get the immediate job done but not much else. Spreadsheets are easy to use but difficult to master. They are ok when they are well designed, use a small amount of data and are to be managed by one person, but bad when large amounts of data is to be managed by many people. Data integrity is a problem because the data is often entered without being checked or verified. One typo can give you an erroneous result and the spreadsheet will not warn you. They and the errors they hold are easy to copy.

Spreadsheets are best used to model a problem, to test calculations or the simulation of a wide variety of variables, not as pseudo databases. If you use spreadsheets to store data in your business you are looking for trouble, there is a better way.