innodb_thread_concurrency vs slave_parallel_workers
These two variables have nothing to do with each other. One is at InnoDB level, the other is at SQL level (and there are many engines aside from InnoDB). They may seem similar because in the case of a very crowded server they could limit the concurrency, sacrifying if for better latency. A higher value for both values (or 0, which means unlimited, for innodb_thread_concurrency) will often result in a higher number of threads running on a particular node. This is then only thing where I can think they can relate.

innodb_thread_concurrency is used by the innodb scheduler to change the number of active foreground threads (the ones retrieving your data from the buffer pool or writing to it an committing to the transaction log). You can read a more in depth explanation about the InnoDB scheduler here: MySQL Performance Blog. Please note that this blog post is ancient, mysql concurrency has improved a lot in 5.6 and 5.7, and my recommendation is to leave this variable as 0 and, if necessary, control the concurrency at used level with a pool of connections.

slave_parallel_workers is a replication slave-only thing. It tells how many sql threads should be executing at the same time trying to apply in parallel the pending changed brought from the master with the io thread. This will not work in stable releases (5.6 series) very well unless you have a multi-tenant database, as changes will only be applied in parallel for diferent schemas with no cross-database queries (so, if you have 2 databases, concurrency will always be 2 or less).

Of course, theoretically, too many slave workers could end up producing too much innodb concurrency, but the odds of that are very low. It makes no sense, however, to setup innodb_threads_concurrency to 1 and slave_parallel_workers to 100, because you will limit your slave change application.

Typically, you will want to not touch innodb_thread_concurrency (leave it to 0, no maximum concurrency limited) and set slave_parallel_workers to the number of real different schemas you have (not having into account mysql, information_schema, etc.) and can write in parallel (useful, for example, if you had one schema per wordpress installation and lots of writes).